Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.6.0
-
Linux + Windows
Description
I experience some infrequent crashes at stopping an Axis server using
axis2_http_server_stop(...);
axis2_transport_receiver_free(...);
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) ...
But: - axis2_transport_receiver_free() indirectly calls
axis2_http_server_free() which in turn destroys and frees
server_impl->svr_thread
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)
printf("Listener returned\n");
axis2_transport_receiver_free(...);
This changes things a bit, now the crash comes later in
axis2_http_svr_thread_run
axutil_thread_pool_get_thread(..., axis2_svr_thread_worker_func
...
axutil_stream_free
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.
axis2_http_svr_thread_run(...)
{
...
socket = (int)axutil_network_handler_svr_socket_accept(env,
svr_thread-> listen_socket);
if(svr_thread->stopped)
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
+patch.