Re: [Libevent-users] random crashed by [err] event_queue_remove:not on queue 8

[Tony Qin <anqin.qin@xxxxxxxxx>]

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 <nickm@xxxxxxxxxxxxx> wrote:
> 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.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.