Bug 808567

Summary: Virt-viewer spice window gets closed during migration with video running in Windows guest
Product: Red Hat Enterprise Linux 6 Reporter: Bill Sanford <bsanford>
Component: spice-gtkAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.3CC: acathrow, cfergeau, dblechte, dyasny, marcandre.lureau, mkrcmari, pvine
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spice-gtk-0.11-8.el6 Doc Type: Bug Fix
Doc Text:
No documentation needed.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 08:19:41 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Bill Sanford 2012-03-30 14:08:27 EDT
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
Comment 2 Marc-Andre Lureau 2012-03-30 19:43:52 EDT
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,
Comment 6 Marc-Andre Lureau 2012-04-20 09:18:49 EDT
    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.
Comment 9 errata-xmlrpc 2012-06-20 08:19:41 EDT
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