On 01/08/2016 11:24, Marc-André Lureau wrote: > Hi > > ----- Original Message ----- >> >> >> On 27/07/2016 23:37, Laszlo Ersek wrote: >>> It seems to me that QEMU deadlocks when it tries to emit the >>> SPICE_DISCONNECTED event. >>> >>> (Note that I can't find "handle SPICE_DISCONNECTED" in the libvirtd log >>> even in the successful case (i.e., when QEMU is built at the parent of >>> 3d344c2aabb7).) >>> >>> Apparently audio_atexit() is triggered when QEMU is returning from >>> main() -- or calling exit() --, which somehow results in QEMU trying to >>> send a SPICE_DISCONNECTED event through the monitor? I guess the monitor >>> has been long dead by then. >>> >>> Hmmm, this gives me an idea... What happens if I remove the following >>> fragment from my domain XML? >>> >>> <sound model='ich6'> >>> <address type='pci' domain='0x0000' bus='0x02' slot='0x07' >>> function='0x0'/> >>> </sound> >>> >>> Yeah, the hang disappears, shutdown works just fine. It's a spice audio >>> bug after all, apparently. Sorry for reporting it in this thread! :) I'm >>> adding Gerd to the address list. >>> >>> To reiterate: this patch (commit 3d344c2aabb7) does *not* cause the >>> symptom, it only exposes an independent bug that causes the symptom. >>> And, I can work around that for now, by removing sound devices. >> >> I think the issue here is that the monitor is gone by the time >> audio_atexit is called. It is caused by commit >> c1111a24a3358ecd2f17be7c8b117cfe8bc5e5f8. >> >> The fix is to move the audio_atexit call to main before >> qemu_chr_cleanup, but I'm not sure how to deal with coreaudio_atexit. > > alternatively, cleanup the monitor before cleaning up the chardev? I was just > looking at that, see wip patch attached.
This patch is a good idea because it avoids a dangling pointer (and avoids touching the mess that is coreaudio_atexit). Paolo
