On Fri, Mar 30, 2012 at 08:45:35AM -0500, Serge Hallyn wrote:
Quoting Daniel Veillard (veillard@redhat.com):
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 -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/