2009/11/26 Daniel P. Berrange <berrange@redhat.com>:
If QEMU shuts down while we're in the middle of processing a monitor command, the monitor will be freed, and upon cleaning up we attempt to do qemuMonitorUnlock(priv->mon) when priv->mon is NULL.
To address this we introduce proper reference counting into the qemuMonitorPtr object, and hold an extra reference whenever executing a command.
* src/qemu/qemu_driver.c: Hold a reference on the monitor while executing commands, and only NULL-ify the priv->mon field when the last reference is released * src/qemu/qemu_monitor.h, src/qemu/qemu_monitor.c: Add reference counting to handle safe deletion of monitor objects
The locking pattern below results in destroying a locked mutex. It this intended? qemuMonitorLock(mon); [...] if (qemuMonitorUnref(mon) > 0) qemuMonitorUnlock(mon); Well, this patch makes the TCK deadlock for me, seems to be a lock ordering issue combined with a race condition; it doesn't happen every run. I don't understand all details of the locking and refcounting scheme of the QEMU monitor yet, it's quite complex and gets even more complex. I attached some GDB and Valgrind traces. Debugging is hindered by libvirtd blocking on poll() in virEventRunOnce() often and I haven't found out why yet. Matthias