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.
