> Mike Christie wrote:
>> Mike Christie wrote:
>>> 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?
> I think I made a mistake here. In the patch I sent, leave_event_loop
> could be 0 and I would still return error to the parent. The parent
> would send a SIGTERM to the child and thus prevent the child from
> freeing up the conn->context_pool[i] structures through
> free_initiator().
> So, looks like my patch was not the right fix and we are back to square
> one now.
> +static mgmt_ipc_err_e
> +mgmt_ipc_check_eventloop(queue_task_t *qtask) {
> +     if(!leave_event_loop)
> +             return MGMT_IPC_ERR_INTERNAL;
> +     return MGMT_IPC_OK;
> +}
> Somehow the conn->context_pool[i] is being freed up before the child
> calls free_initiator(). This causes the double free.
>> I tried to replicate this here but did not see the problem. Could you 
>> maybe run iscsistart in valgrind and send that output?

Maybe it is related to this

That ppc code is run first as a sort of probe to see if ppc iscsi boot 
is being used. If not then we switch and check ibft.

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