On Tue, Mar 26, 2013 at 10:17:01 -0600, Eric Blake wrote: > On 03/26/2013 09:52 AM, Jiri Denemark wrote: > > Despite of the comment stating virNetClientIncomingEvent handler should > > s/of // > > > never be called with either client->haveTheBuck or client->wantClose > > set, there is a sequence of events that may lead to both booleans being > > true when virNetClientIncomingEvent is called. However, when that > > happens, we must not immediately close the socket as there are other > > threads waiting for the buck and they would cause SIGSEGV once they are > > woken up after the socket was closed. Another thing is we should clear > > all remaining calls in the queue after closing the socket. > > > > The situation that can lead to the crash involves three threads, one of > > them running event loop and the other two calling libvirt APIs. The > > event loop threads detects an event on client->sock and calls > > virNetClientIncomingEvent handler. But before the handler gets a chance > > to lock client, the other two threads (T1 and T2) start calling some > > APIs. T1 gets the buck and detects EOF on client->sock while processing > > its RPC call. Since T2 is waiting for its own call, T1 passes the buck > > onto it and unlocks client. But before T2 gets the signal, the event > > s/onto/on to/ > > > loop thread wakes up, does its job and closes client->sock. The crash > > happens when T2 actually wakes up and tries to do its job using a closed > > client->sock. > > --- > > src/rpc/virnetclient.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > Tricky analysis, but I agree with the outcome. Definitely worth fixing > in 1.0.4. > > ACK. Thanks, I fixed one more typo in the commit message and pushed. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list