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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

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


Hm.  Looks like we're missing a couple levels of stack here.  Is it
doable to compile with inlining turned off so we can see what's
calling what going on for real?  (-fno-inline should do it under gcc,
I think)

Also, maybe consider running under valgrind if you can.  It often
notices screwy memory stuff before a crash actually occurs.

 [...]
> It seems that by the time _bufferevent_run_eventcb() is called, its
> bufev argument ends up being 0x20. No idea what to do next.

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.

hth,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.