axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Gentsch (JIRA)" <>
Subject [jira] Created: (AXIS2C-1537) HTTP server crashes during shutdown
Date Sun, 20 Feb 2011 14:14:38 GMT
HTTP server crashes during shutdown

                 Key: AXIS2C-1537
             Project: Axis2-C
          Issue Type: Bug
          Components: transport/http
    Affects Versions: 1.6.0
         Environment: Linux + Windows
            Reporter: Thomas Gentsch

I experience some infrequent crashes at stopping an Axis server using

Now it looks to me as if
 - axis2_http_server_stop() just closes the listening socket of the 
   listener thread and sets "stopped" to true
 - then, the listener thread (in axis2_http_svr_thread_run) returns 
   from axutil_network_handler_svr_socket_accept()
   and checks the worker:
    if (!svr_thread->worker) ...
 - axis2_transport_receiver_free() indirectly calls 
   axis2_http_server_free() which in turn destroys and frees 

I'm not sure yet whether I understand this completely, but it looks as
if then (depending on which thread is faster) the listener accessed
memory now already freed.

In a first approach I moved in my own server prog the
axis2_transport_receiver_free() after starting the HTTP server, i.e.:
  if(axis2_transport_receiver_start(srv, env) == AXIS2_FAILURE)
    // err handling
  printf("Listener returned\n");

This changes things a bit, now the crash comes later in
 axutil_thread_pool_get_thread(..., axis2_svr_thread_worker_func

But the question is: Is it right that the listener continues at all
after the accept() returns a failure?
I have inserted another test for "stopped" and, if so, break the
listener loop and, so far, it seems to be ok.

  socket = (int)axutil_network_handler_svr_socket_accept(env,
                svr_thread-> listen_socket);

Does that ring any bells? Could somebody more experienced please think
about that scenario (while having a look into the code)?

I'll do more testing and, hoping that all keeps working, create a defect

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message