On 09/26/2012 08:56 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
Some users report (very rarely) seeing a deadlock in the QEMU monitor callbacks
Thread 10 (Thread 0x7fcd11e20700 (LWP 26753)): at util/threads-pthread.c:85 at conf/domain_conf.c:14256 vm=0x7fcccc00a850) at qemu/qemu_process.c:1026 at qemu/qemu_monitor.c:249 at util/virobject.c:139 at qemu/qemu_monitor.c:860 vm=vm@entry=0x7fcccc00a850, reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED, flags=flags@entry=0) at qemu/qemu_process.c:4057 flags=<optimized out>) at qemu/qemu_driver.c:1977 domain=domain@entry=0x7fccf00c1830, flags=1) at libvirt.c:2256
At frame #10 we are holding the domain lock, we call into qemuProcessStop() to cleanup QEMU, which triggers the monitor to close, which invokes qemuProcessHandleMonitorDestroy() which tries to obtain the domain lock again. This is a non-recursive lock, hence hang.
Since qemuMonitorPtr is a virObject, the unref call in qemuProcessHandleMonitorDestroy no longer needs mutex protection. The assignment of priv->mon = NULL, can be instead done by the caller of qemuMonitorClose(), thus removing all need for locking.
ACK. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org