[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] Re: help with debugging
Alright, i think i found the bug -- still not sure whether it's me or
the library, but:
Valgrind trace:
==8517==
==8517== Invalid read of size 4
==8517== at 0x80A1AF1: evhttp_request_get_input_buffer (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8071FE2:
_ZN6serverL13http_event_cbEP14evhttp_requestPv (server.cpp:730)
==8517== by 0x809EB33: evhttp_error_cb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x809EB9B: evhttp_connection_cb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x80927B8: _bufferevent_run_eventcb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8094406: bufferevent_connect_getaddrinfo_cb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x80ABB0A: evdns_getaddrinfo_gotresolve (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x80A2FC4: reply_run_callback (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8087C29: event_process_deferred_callbacks (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8087D16: event_process_active (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8088239: event_base_loop (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8087D45: event_base_dispatch (in
/home/mihai/frogmod-justice/frogserv)
==8517== Address 0x40 is not stack'd, malloc'd or (recently) free'd
==8517==
==8517== Process terminating with default action of signal 11 (SIGSEGV)
==8517== Access not within mapped region at address 0x40
==8517== at 0x80A1AF1: evhttp_request_get_input_buffer (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8071FE2:
_ZN6serverL13http_event_cbEP14evhttp_requestPv (server.cpp:730)
==8517== by 0x809EB33: evhttp_error_cb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x809EB9B: evhttp_connection_cb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x80927B8: _bufferevent_run_eventcb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8094406: bufferevent_connect_getaddrinfo_cb (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x80ABB0A: evdns_getaddrinfo_gotresolve (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x80A2FC4: reply_run_callback (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8087C29: event_process_deferred_callbacks (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8087D16: event_process_active (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8088239: event_base_loop (in
/home/mihai/frogmod-justice/frogserv)
==8517== by 0x8087D45: event_base_dispatch (in
/home/mihai/frogmod-justice/frogserv)
It looks to me like even though there is a dns error, the http event
function is still called
(_ZN6serverL13http_event_cbEP14evhttp_requestPv in this case -
server::http_event_cb(evhttp_request *, void *) - that's what the
garble means).
static void http_event_cb(struct evhttp_request *req, void *arg) {
char *line;
evbuffer *buf = evhttp_request_get_input_buffer(req);
while((line = evbuffer_readln_nul(buf, NULL,
EVBUFFER_EOL_ANY))) { // the readln_nul function is custom -- does the
same as readln, but also stops at EOF
printf("HTTP: %s\n", line);
free(line);
}
}
Basically my http event function reads from the request's input buffer
(the http response) and outputs it to console.
So now it comes down to a question - how do i determine inside
http_event_cb whether i've received an error or success?
Thanks for the help,
Mihai
On Fri, Sep 17, 2010 at 5:29 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> 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
>
>
> 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.
>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.