Re: [Libevent-users] Signals and priority queues

[Ralph Castain <rhc@xxxxxxxxxxxx>]

If it helps, I have now confirmed that I *can* activate the t2 event during the t1func callback in my example *provided* I called event_assign on it prior to entering event_base_loop. It is also okay for me to event_add the t2 event during the callback - I am simply not allowed to event_assign *and* activate it there.

However, it is okay to assign the event during the callback so long as I don't activate it until after I return.

Seems a little strange to me - is this the intended behavior?


On Jan 6, 2012, at 2:09 AM, Ralph Castain wrote:

> I've pursued this further, and now I am wondering if this is a libevent issue - or perhaps I'm misusing the library. The cause of the segfault appears to be the activation of the event created during the event callback. If I delay activation so it occurs outside of the callback, then everything works cleanly (see attached revised example).
> 
> This doesn't appear to have anything to do with event priorities - I get the same behavior with or without defining multiple priorities. Hence my suspicion that I'm not using the library as expected.
> 
> Could you perhaps clarify this situation? Is activating a newly-defined event during an event callback not permitted?
> 
> Thanks
> Ralph
> 
> <evpri-test.c>
> 
> On Jan 5, 2012, at 8:01 PM, Ralph Castain wrote:
> 
>> Well, after playing around a bit, I did finally manage to recreate the scenario in my main program using your example. The attached program reliably crashes with the following output and backtrace:
>> 
>> Ralph:system rhc$ ./evpri-test
>> Libevent 2.0.13-stable-openmpi
>> SIGNAL EVENT DEFINED
>> FIRST TERMINATION EVENT DEFINED
>> CAUGHT FIRST TERMINATION EVENT
>> SECOND TERMINATION EVENT DEFINED
>> Segmentation fault (core dumped)
>> 
>> 
>> #0  0x0000000100151ab4 in event_queue_remove (base=0x1003000a0, ev=0x7fff5fbff040, queue=8) at event.c:2499
>> 2499			TAILQ_REMOVE(&base->activequeues[ev->ev_pri],
>> (gdb) where
>> #0  0x0000000100151ab4 in event_queue_remove (base=0x1003000a0, ev=0x7fff5fbff040, queue=8) at event.c:2499
>> #1  0x0000000100150d88 in event_del_internal (ev=0x7fff5fbff040) at event.c:2216
>> #2  0x000000010014e26c in event_process_active_single_queue (base=0x1003000a0, activeq=0x100300320) at event.c:1303
>> #3  0x000000010014e85b in event_process_active (base=0x1003000a0) at event.c:1396
>> #4  0x000000010014ee40 in opal_libevent2013_event_base_loop (base=0x1003000a0, flags=1) at event.c:1593
>> #5  0x0000000100001bbe in main (argc=1, argv=0x7fff5fbff398) at evpri-test.c:110
>> 
>> This is clearly not a problem in libevent itself, but I'm rather lost as to the cause. Only thing I can think is that both of the termination events reference -1 as their fake fd, and perhaps this is causing confusion.
>> 
>> Any thoughts would be most appreciated!
>> Ralph
>> 
>> 
>> <evpri-test.c>
>> 
>> 
>> On Jan 5, 2012, at 10:28 AM, Nick Mathewson wrote:
>> 
>>> On Wed, Jan 4, 2012 at 2:50 PM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
>>>> Hmmm...Well, your program works fine for me too, and I haven't succeeded in making it crash, so I suspect it is a bug in my code (which is what I expected). I configured with libevent debug enabled, but saw no output from libevent (the code still crashes as before). Is there anything else I need to set to get diagnostic output from libevent?
>>> 
>>> Have a look at event_enable_debug_mode()
>>> 
>>> 
>>> 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.