Thanks for the patch. wrote:
> Resending because earlier patch had a small typo. 
>> Ulrich wrote: 
>> On 17 Mar 2009 at 22:33, wrote:
>>> The issue is caused because child is trying to free up the session
> and 
>>> connections that the parent had setup.
>> Hi!
>> Not knowing the source, I wonder: Parent and child (both processes?)
> have their own copy of memory, so each one can free within its own copy
> of memory. 
>> If they are calling some external process to free something, it's most
> likely a race condition, because the "server" should only allow to free
> anything
>> exactly one.
> Yes. You are right. There was actually a race condition because of the
> event loop being stopped twice.
> Looks like I got a patch with the real scenario affecting the bug.
> Please note I am marking the attempt by the parent to stop the event
> loop when it has already stopped as an internal error. 
> I am not sure if we are supposed to log the error but yet this
> serializing the stopping of event loop will fix the issue of freeing
> twice.
> I think we don't have to call stop_event_loop if event_loop is already
> stopped.

We should not have to call stop_event_loop if the event_loop is already 
stopped. What I am wondering is how the event loop is stopped by anyone 
other than the call to stop_event_loop? It looks like it could happen if 
there was a signal or if there was a poll error. Did you see either of 
those in your test?

Even if we did stop_event_loop when event_loop is not running, I am not 
sure I how this causes a double free or corruption. If event_loop is 
stopped then will stop_event_loop return an error and that will cause us 
to send a sigterm to the parent but the parent could have completed? 
Would that return the same error you are seeing?

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to