Re: [libvirt] [PATCH 03/14] Fix crash when deleting monitor while a command is in progress
2009/11/26 Daniel P. Berrange <berrange(a)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
Attachments:
- deadlock-gdb2.txt (text/plain — 4.7 KB)
- deadlock-gdb1.txt (text/plain — 4.5 KB)
- deadlock-helgrind.txt (text/plain — 2.0 KB)