Hide Forgot
Description of problem: Using virt-viewer on a RHEL 6.3 client on RHEL 6.3 hosts and RHEV-M ic55, I have a Windows guest open. I play a video and then migrate the guest in the middle of the video. As the migration is taking place, the spice window is closed. Spice client RHEL 6.3 - 64bit virt-viewer-0.5.2-3.el6.x86_64 spice-gtk-0.11-5.el6.x86_64 spice-client-0.8.2-13.el6.x86_64 spice-usb-share-4.9-9.el6.x86_64 spice-xpi-2.7-15.el6.x86_64 kmod-kspiceusb-rhel60-4.9-14.el6.x86_64 spice-gtk-python-0.11-5.el6.x86_64 spice-vdagent-0.8.1-3.el6.x86_64 spice-glib-0.11-5.el6.x86_64 I tailed /var/log/messages and at the migration where the spice window is closed: Mar 30 13:24:53 dhcp-10-16-62-59 spice: Warning: abort Mar 30 13:24:54 dhcp-10-16-62-59 spice: Warning: abort Mar 30 13:24:54 dhcp-10-16-62-59 spice: Warning: abort Mar 30 13:24:54 dhcp-10-16-62-59 spice: Warning: abort Mar 30 13:24:55 dhcp-10-16-62-59 spice: Warning: abort Mar 30 13:24:55 dhcp-10-16-62-59 spice: spicec execution failed Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Open Windows guest with virt-viewer 2. Migrate VM playing video from the Admin Portal. 3. Actual results: Spice window is closed. Expected results: Spice windows stays open Additional info: spice-vdagent-0.8.1-3.el6.x86_64 spice-server-0.10.1-4.el6.x86_64 spice host RHEL 6.3 - 64bit rhevm ic155 qemu-kvm-0.12.1.2-2.246.el6.x86_64 qemu-kvm-tools-0.12.1.2-2.246.el6.x86_64 Spice guest Windows 7 or XP qxl x.1.0.10012 rhev-usb-msi-4.7-8
Proposed patch sent upstream. This is what I could reproduce (this is a racy bug, doesn't always happen): When the display channel is destroyed, we disconnect all signals handlers, but we don't remove the reference on the primary surface data, and that can lead to crashes in a later expose event, reusing the canvas surface (ex, if scaling is disabled). Call primary_destroy() when disconnecting the channel from the widget. We now keep the primary surface during channel reset (right after disconnect for example), so the primary surface can be eventually recycled, and the widget still holds a valid reference until the signal is received. The primary surface is ultimately destroyed during finalize, or if the new primary surface size doesn't match. Program received signal SIGSEGV, Segmentation fault. __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2130 2130 lddqu -68(%rsi), %xmm0 Missing separate debuginfos, use: debuginfo-install gtk2-engines-2.20.2-2.fc15.x86_64 libusb1-1.0.9-0.3.rc1.fc16.x86_64 p11-kit-0.6-1.fc16.x86_64 (gdb) bt at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2130 srclen=<optimized out>, srcinc=4096, destinc=68, height=<optimized out>, half_order=0) at /usr/include/bits/string3.h:52 dest_bits_per_pixel=32, req_yoffset=<optimized out>, req_xoffset=0, image=0x7fffffffb9a0, req=<optimized out>, dpy=0x64a630) at PutImage.c:821 req_height=<optimized out>, req_width=<optimized out>, y=<optimized out>, x=0, req_yoffset=<optimized out>, req_xoffset=0, image=0x7fffffffb9a0, gc=0xa817e0, d=33554452, dpy=0x64a630) at PutImage.c:870 req_xoffset=0, req_yoffset=<optimized out>, x=0, y=26, req_width=17, req_height=20, dest_bits_per_pixel=32, dest_scanline_pad=32) at PutImage.c:908 image=0x7fffffffb9a0, req_xoffset=0, req_yoffset=0, x=0, y=26, req_width=17, req_height=20) at PutImage.c:1027 image=<optimized out>, src_x=0, src_y=0, width=17, height=20, dst_x=0, dst_y=26) at cairo-xlib-surface.c:1357 ---Type <return> to continue, or q <return> to quit---c height=20, width=17, dst_y=26, dst_x=0, src_y=<optimized out>, src_x=<optimized out>, pattern=0x7fffffffc6b0, op=CAIRO_OPERATOR_OVER, surface=0xb9a650) at cairo-xlib-surface.c:2403 dst_y=26, dst_x=0, mask_y=0, mask_x=0, src_y=26, src_x=0,
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation needed.
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-2012-0767.html