Re: [Libevent-users] Re: help with debugging

[Mark Ellzey <mthomas@xxxxxxxxxx>]

On Fri, Sep 17, 2010 at 10:29:08AM -0400, Nick Mathewson wrote:
> On Fri, Sep 17, 2010 at 5:22 AM, Mihai Draghicioiu
> <mihai.draghicioiu@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.