humm.... when I enable the debug mode in libevent, it will dump GB-level log and not easy to check specific event. Also, the crash does not always happen in any time running.
Has any quickly fix there? I try to disable the event_errx() in event_queue_remove() and let server alive. However, it seems the libevent's behavior become innormal and is more esaier crash than before. BTW, I have tested in kernel 2.6.9 and 2.6.32. It seems 2.6.32 more stable than 2.6.9, but still cause the bug. Any idea? On Tue, Feb 19, 2013 at 9:51 AM, Nick Mathewson <ni...@freehaven.net> wrote: > On Sun, Feb 17, 2013 at 10:09 PM, Tony Qin <anqin....@gmail.com> wrote: >> Hi all, >> >> I uses the libevent-2.0.19-stable in my rpc server to send data from >> client-end to server-end. However, my server is always "exist" by >> libevent (by event_errx()). >> >> Checked log and fond the follow message: >> >> event_queue_remove: 0x7ea588(fd 17) not on queue 8 >> >> So, after add abort() in event_exit() and dump the core, the core >> stack is as following: > > Hm. This means that while we were processing active events (in > event_process_active_single_queue), when we went to remove one from > the queue of active events (EVLIST_ACTIVE, queue 8), it didn't have > the right flag set. > > This really shoudldn't be happening unless there's an internal error > in the code somewhere: in your code, or in Libevent's code. For one > thing, 2.0.19-stable is a little old, but none of the fixes in > 2.0.20-stable or 2.0.21-stable look like they'd fix a bug that could > cause this. > > One thing that can cause bogus behavior like this is if an event is > passed to event_set() or event_assign(), or if you edit the event's > internals, without first passing the event to event_del(). Some ways > you could try to diagnose that to find out if it's happening: > > * Make sure you built libevent with debugging support, and then use > event_enable_debug_mode() to get extra run-time debugging checks. > * Try using valgrind or a similar memory access checking tool to see > if there could be any premature free() issues. > * Try running with debug-level logs from libevent to track the > life-history of the offending event object, and see whether anything > strange happens to it before it crashes your program. > > Best of luck, > -- > Nick > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
