Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
For a more detailed explanation -- see commit log of patch
http://patchwork.freedesktop.org/patch/14122/
Cause:
When two items were to be sent to the client (for example in on_new_cursor_channel), at the time the client got disconnected, the first item was cleared, while the second was not (meaning it was meant to be sent to the client).
Consequence:
An assert, that makes sure there are no items to be sent when the client is removed, was hit causing spice-server to abort.
Fix:
The second item is now cleared too.
Result:
The assert does not hit and spice-server continues to run.
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
Comment 1Marc-Andre Lureau
2013-03-05 15:58:59 UTC
please move to appropriate component.
Comment 7Christophe Fergeau
2013-03-13 10:29:42 UTC
(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 ()
Comment 9Christophe Fergeau
2013-03-13 13:11:45 UTC
Do you have a longer qemu log from before the crash occurs?
Comment 11Christophe Fergeau
2013-03-15 13:32:42 UTC
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 ;)
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
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