On Fri, Jul 30, 2010 at 11:11:38AM -0600, Eric Blake wrote: > On 07/30/2010 11:09 AM, Daniel Veillard wrote: > > On Fri, Jul 30, 2010 at 09:52:47AM -0600, Eric Blake wrote: > >> Spotted by clang. The qemuConnectMonitor one is an outright bug, > >> the other two are cosmetic. > >> > >> * src/qemu/qemu_monitor.c (qemuMonitorClose): Kill dead store. > >> * src/qemu/qemu_driver.c (qemudDomainSaveImageStartVM): Likewise. > >> (qemuConnectMonitor): Don't lose error status. > >> --- > >> src/qemu/qemu_driver.c | 2 -- > >> src/qemu/qemu_monitor.c | 4 +--- > >> 2 files changed, 1 insertions(+), 5 deletions(-) > >> > >> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c > >> index 098f4da..57b8271 100644 > >> --- a/src/qemu/qemu_driver.c > >> +++ b/src/qemu/qemu_driver.c > >> @@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct qemud_driver *driver, virDomainObjPtr vm) > >> ret = qemuMonitorSetCapabilities(priv->mon); > >> qemuDomainObjExitMonitorWithDriver(driver, vm); > >> > >> - ret = 0; > >> error: > >> if (ret < 0) > >> qemuMonitorClose(priv->mon); > > > > Hum, if we do this we change the behaviour in case of errors in > > qemuMonitorSetCapabilities(), I wonder if this wasn't there to avoid > > failing in that case, and if this was the case then it's the first > > affectation we need to remove. I would wait until this gets clarified > > (qemuMonitorSetCapabilities failure may not be a blocking factor to > > starting a guest ...) > > This bug was was introduced in commit e72cc3c, with dwalsh's patch on > May 27. We were doing the correct thing before then, so only 0.8.2 > contains a problem where failure to connect to the monitor is undetected. okidoc, ACK, sorry for the burden :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list