I have a server using evhttp, which was running quite stably on 2.0.8.
It uses a pthreads-based worker pool, but accepts http connections in
the network thread, using one event base.
On 2.0.10 and 2.0.11 things are now crashing or locking very quickly.
The code to startup the server in the network thread is pretty routine:
evthread_use_pthreads();
base = event_base_new();
http = evhttp_new(base);
evthread_make_base_notifiable(base);
evhttp_set_gencb(http, LENetwork::NetworkHandler, this);
evhttp_bind_socket(http, "0.0.0.0", portnum);
event_base_dispatch(base);
The callback immediately hands off the *evhttp_request *pointer to a
worker, which then winds up calling *evhttp_send_reply* (in that worker
thread, not the network thread).
Running under libevent-2.0.11, my Linux machine just locks up and stops
accepting connections, and I can't find much going on in gdb.
Helgrind complains about things like this:
==29140== Possible data race during write of size 4 at 0x40b51d4 by
thread #15
==29140== at 0x810175F: bufferevent_setcb (bufferevent.c:351)"
On OpenSolaris, the problem takes more time to show, I can force
consistent segfaults. The crashing stack appears to be:
#0 bufferevent_setcb (bufev=0x6b696d2f, readcb=0, writecb=0x8148110
<evhttp_write_cb>, eventcb=0x814cf60 <evhttp_error_cb>, cbarg=0x82a06a8)
at bufferevent.c:345
345 BEV_LOCK(bufev);
Current language: auto; currently c
(gdb) bt
#0 bufferevent_setcb (bufev=0x6b696d2f, readcb=0, writecb=0x8148110
<evhttp_write_cb>, eventcb=0x814cf60 <evhttp_error_cb>, cbarg=0x82a06a8)
at bufferevent.c:345
#1 0x0814adff in evhttp_write_buffer (evcon=0x82a06a8, cb=<value
optimized out>, arg=<value optimized out>) at http.c:377
So both platforms are reporting some problem with *bufferevent_setcb*.
*Questions: *is bufferevent supposed threadsafe for this case? I suppose
I haven't verified if my technique of handing evhttp_request over the
thread boundary is supposed to work or not...it has just been working
for quite a long time under earlier versions of libevent.
Why did it work so reliably in 2.0.8 and 2.0.7 and not in 2.0.10/11?
Any help fixing or tracking down further?
thanks,
mike
