On 09/26/2012 08:56 AM, Daniel P. Berrange wrote: > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> > > 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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list