Red Hat Bugzilla – Bug 918169
Closing window while playing video causes VM to crash
Last modified: 2017-02-06 10:16:57 EST
Created attachment 705532 [details] This is what appears in the log generated by qemu. Tried attaching gdb but it didn't fail... also after installation of debuginfo, no stack was attached Description of problem: Windows 7 32bit; both client and guest. Playing back a video (e.g. flash video in a browser) and closing the client window makes the VM crash Version-Release number of selected component (if applicable): mingw-virt-viewer-0.5.3-20 spice-server-0.12.0-12.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.348.el6.x86_64 How reproducible: 80% Steps to Reproduce: 1. Start a Vm (preferably Windows) 2. Connect to it (from a windows client (hasn't been observed with rhel) 3. Start watching a video 4. Close the virt-viewer window Actual results: VM crashes Expected results: VM should be up
please move to appropriate component.
(In reply to comment #0) > Created attachment 705532 [details] > This is what appears in the log generated by qemu. Tried attaching gdb but > it didn't fail... also after installation of debuginfo, no stack was attached You never can reproduce it with qemu running in gdb? Can you get a coredump instead, and then grab the backtrace from it? You probably need to run 'ulimit -c unlimited' to enable coredump generation
Tried reproducing repeatedly with gdb attached: [New Thread 0x7f3458b14700 (LWP 14014)] Program received signal SIGABRT, Aborted. 0x00007f345e1fb8a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00007f345e1fb8a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f345e1fd085 in abort () at abort.c:92 #2 0x00007f345e2397b7 in __libc_message (do_abort=2, fmt=0x7f345e320f80 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 #3 0x00007f345e23f0e6 in malloc_printerr (action=3, str=0x7f345e3212e0 "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6311 #4 0x00007f345e241c13 in _int_free (av=0x7f345e557e80, p=0x7f34631e6210, have_lock=0) at malloc.c:4811 #5 0x00007f345c07e5c4 in celt_free (mode=0x7f34631dc700) at os_support.h:78 #6 celt051_mode_destroy (mode=0x7f34631dc700) at modes.c:433 #7 0x00007f345ea48c77 in snd_disconnect_channel (channel=0x7f346304c6c0) at snd_worker.c:216 #8 0x00007f345ea498de in snd_receive (data=0x7f346304c6c0) at snd_worker.c:435 #9 0x00007f345ea499a0 in snd_event (fd=<value optimized out>, event=<value optimized out>, data=<value optimized out>) at snd_worker.c:489 #10 0x00007f346089840f in ?? () #11 0x00007f34608ba9ba in ?? () #12 0x00007f346089b178 in main ()
Do you have a longer qemu log from before the crash occurs?
Created attachment 709615 [details] From start to crash
I could not reproduce while playing back youtube videos. What seems to be happening is that the sound playback channel gets disconnect and frees the celt data structures, and after that happens, a callback gets called as there is data to read for the sound channel, reading the data fails as the channel has been disconnected, and this triggers a cleanup, where spice tries again to free the celt data, leading to the crash. No idea why this happens though ;)
Can you please attach a qemu log with the highest spice debug level?
I posted a patch series, starting with http://patchwork.freedesktop.org/patch/14122/ I managed to reproduced the bug with guest playing video in a loop, and a script on a windows client that connect and disconnects the remote-viewer to the VM repeatedly. During the disconnection, I also hit another assert that is fixed by this patch series: (./x86_64-softmmu/qemu-system-x86_64:660): Spice-ERROR **: red_channel.c:1987:red_client_destroy: assertion `rcc->send_data.size == 0' failed
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1571.html