Hi Nick, On Fri, Mar 2, 2012 at 9:00 PM, Nick Mathewson <ni...@freehaven.net> wrote: > On Fri, Mar 2, 2012 at 10:00 AM, Daniel Janzon <jan...@gmail.com> wrote: >> I found a similar report in the mailing list archive, where it was >> concluded that this can happen when event_set is called after >> event_add. In this case, however, the only place in the code where >> event_set is called, is on the line before even_add. > > That isn't a guarantee unless you're *certain* that the memory that > you're calling event_set() on is not a currently added event.
Quite true! I guess it must be that that's happening although I can't find any error in the code. > Libevent 2.0's debug-mode feature would catch this case, if you have a > chance to build against 2.0 some time and turn on debug mode. > > As a fail-safe mode, you can stop using event_set() and write your own > (forward-compatible!) event_new() and event_free(), so you don't need > to worry about accidentally re-assigning an event. Thereby trading an infinite loop for a memory leak. Not a bad deal :) > Alternatively, if the memory that you're calling event_set() on has a > known initial state (for example, you're getting it from calloc()), > you could check its ev_flags values before you call event_set on it; > that might turn up the problem. I reuse the event objects millions of times. I guess memsetting them to zero before event_set may smoke out the bug. I'll try that. Regards, Daniel *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
