Quoting Daniel Veillard (veillard@xxxxxxxxxx): > On Fri, Mar 30, 2012 at 08:45:35AM -0500, Serge Hallyn wrote: > > Quoting Daniel Veillard (veillard@xxxxxxxxxx): > > > On Fri, Mar 16, 2012 at 02:37:42PM +0800, Wen Congyang wrote: > > > > When qemu cannot start, we may call qemuProcessStop() twice. > > > > We have check whether the vm is running at the beginning of > > > > qemuProcessStop() to avoid libvirt deadlock. We call > > > > qemuProcessStop() with driver and vm locked. It seems that > > > > we can avoid libvirt deadlock. But unfortunately we may > > > > unlock driver and vm in the function qemuProcessKill() while > > > > vm->def->id is not -1. So qemuProcessStop() will be run twice, > > > > and monitor will be freed unexpectedly. So we should set > > > > vm->def->id to -1 at the beginning of qemuProcessStop(). > > > > Oh, uh, Huh. This seems like it could be responsible for what I was > > reporting a few days ago (*1). I spent most of yesterday trying to > > track it down, only to finally realize that the QemuProcessStart would > > silently die at various places. So i was getting ready to send an email > > postulating that what's happening is that a virsh list starts, then > > a virsh start starts, and when the virsh list ends it somehow causes > > the virsh start to be killed. > > > > I'll test and see if this patch fixes it. > > I guess I need to resurect my patch checker, tune it and > make it send warning on patches not ACK'ed or reviewed automatically, > or even better make it a web page to avoid boring people. > http://libvirt.org/git/?p=patchchecker.git;a=summary > > I had that patch on my radar and though I took an awful long time > to review it it's there. > > BTW I'm late for rc2, I will make it tomorrow I guess, sorry about > it this is due to events out of my control :-\ > > Daniel > Alas, this patch (by itself) doesn't fix the issue for me. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list