[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] random crashed by [err] event_queue_remove:not on queue 8
On Sun, Feb 17, 2013 at 10:09 PM, Tony Qin <anqin.qin@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.