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 <r...@open-mpi.org> 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 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.
