On Fri, Sep 17, 2010 at 10:29:08AM -0400, Nick Mathewson wrote: > On Fri, Sep 17, 2010 at 5:22 AM, Mihai Draghicioiu > <[email protected]> wrote: > [...] > > Core was generated by `/home/mihai/frogmod-justice/frogserv'. > > Program terminated with signal 11, Segmentation fault. > > [New process 14829] > > #0 ?evhttp_request_get_input_buffer (req=0x99d90f8) at http.c:3014 > > 3014 ? ?{ > > (gdb) up > > #1 ?0x08091a0e in _bufferevent_run_eventcb (bufev=0x20, what=0) at > > bufferevent.c:264 > > 264 ? ? ? ? ? ? ? ? ? ? bufev->errorcb(bufev, what, bufev->cbarg); > > Current language: ?auto; currently c > > (gdb) > > #2 ?0x080928cd in bufferevent_connect_getaddrinfo_cb (result=-4, > > ai=0x99e3100, arg=0x99d90f8) at bufferevent_sock.c:444 > > 444 ? ? ? ? ? ? ? ? ? ? _bufferevent_run_eventcb(bev, BEV_EVENT_ERROR); > > (gdb) list 434 > > This might or might not be for real. It could just be that by the > time the debugger is invoked, the memory that used to have 'bufev' has > already in _bufferevent_run_eventcb() has become an unused ("dead") > variable, and so the compiler has decided it can be overwritten by > something else. You could toss in an "assert(bufev != 0x20)" there if > you want to be sure , but I wouldn't expect it to trigger. >
In my experience seeing a stacktrace like that is very reminiciant of a threading issue. If your application is threaded, your backtrace looks like garbage, it probably *is* garbage. Mihai, I did look at your code; compiled and ran it in a VM. What exactly triggers the crash? Please contact me off-list. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
