On Wed, Mar 10, 2010 at 1:22 AM, David Titarenco <[email protected]>wrote:
> Niels: > > > On Tue, Mar 9, 2010 at 4:38 PM, Niels Provos <[email protected]> wrote: > >> Hi David, >> >> On Tue, Mar 9, 2010 at 1:00 PM, David Titarenco >> <[email protected]> wrote: >> > My server segfaults/crashes/etc under high load. It's fairly simple and >> > nothing is intrusive. The following is the most recent crash report from >> > earlier today: >> > >> > Program received signal SIGSEGV, Segmentation fault. >> > 0xb7f6c1f6 in evhttp_add_header_internal (headers=0xfffffc40, >> key=0xb7f7fc45 >> > "Connection", value=0xb7f7fc50 "close") at http.c:1467 >> > 1467 TAILQ_INSERT_TAIL(headers, header, next); >> > Current language: auto; currently c >> > (gdb) bt >> > #0 0xb7f6c1f6 in evhttp_add_header_internal (headers=0xfffffc40, >> > key=0xb7f7fc45 "Connection", value=0xb7f7fc50 "close") at http.c:1467 >> > #1 0xb7f6f4a7 in evhttp_send_error (req=0xb7e3af50, error=504, >> > reason=0x813d24b "Update the state. Hit PHP!") at http.c:2050 >> >> Thanks for the report. Where do you get the request pointer from? >> Could you print the contents in gdb? My best guess is that the >> request got freed underneath you for some reason. >> >> Niels. >> *********************************************************************** >> To unsubscribe, send an e-mail to [email protected] with >> unsubscribe libevent-users in the body. >> > > I get my req pointer from an STL map: map<evhttp_request *,bead> that I > iterate over. Now, I wrote a home-made timeout method that uses evtimer for > these long-polling connections (that I call beads). The only thing that I'm > worried about is that the timeout callback might be fired in the middle of a > (long) iteration in case of many connections (could this even happen? - the > server is NOT multithreaded) which in turn also closes the connection and > deletes map entry. But if this weird race condition DOES happen, it _should_ > give me an STL null pointer exception, not a libevent segfault. Moreover, is > there any way to check and see if the req is valid or not, to at least avoid > a server crash? > > Next time I encounter the segfault, I'll print the contents of the req > pointer address. > > David > Crashed again, a few minutes ago: Program received signal SIGSEGV, Segmentation fault. 0xb7bf49b4 in free () from /lib/libc.so.6 (gdb) bt #0 0xb7bf49b4 in free () from /lib/libc.so.6 #1 0xb7ed0798 in mm_free (ptr=0x31313932) at event.c:2407 #2 0xb7ee6d76 in evhttp_response_code (req=0x3131392a, code=503, reason=0x813d288 "ERROR") at http.c:2179 #3 0xb7eec023 in evhttp_send_reply (req=0x9f40570, code=503, reason=0x813d288 "ERROR", databuf=0x9f3f7a0) at http.c:2093 #4 0x081190ef in long_polling_bead (it={_M_node = 0xb7cce170}) at eve.new.cpp:394 #5 0x08119c85 in handle_beads () at eve.new.cpp:485 #6 0x08119cd6 in iterate_cb (fd=-1, event=1, arg=0x0) at eve.new.cpp:490 #7 0xb7ed54f9 in event_base_loop (base=0x9f369c0, flags=0) at event.c:1170 #8 0xb7ed6095 in event_base_dispatch (event_base=0x9f369c0) at event.c:1250 #9 0x08118c93 in main (argc=1, argv=0xbfa3de04) at eve.new.cpp:631 (gdb) x 0x9f40570 0x9f40570: 0x0000000c (gdb) x 0x3131392a 0x3131392a: Cannot access memory at address 0x3131392a (gdb) x 0xb7cce170 0xb7cce170 <main_arena+48>: 0x09f55058 (gdb) -David
