Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 956345 - Spice server aborts after 2 seamless migration
Spice server aborts after 2 seamless migration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-server (Show other bugs)
6.4
Unspecified Unspecified
urgent Severity high
: rc
: ---
Assigned To: Uri Lublin
Desktop QE
: ZStream
Depends On:
Blocks: 961427
  Show dependency treegraph
 
Reported: 2013-04-24 14:22 EDT by Marc-Andre Lureau
Modified: 2013-11-21 02:41 EST (History)
7 users (show)

See Also:
Fixed In Version: spice-server-0.12.0-13.el6
Doc Type: Bug Fix
Doc Text:
See documentation for bug 961427 in http://rhn.redhat.com/errata/RHBA-2013-0866.html
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 02:41:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1571 normal SHIPPED_LIVE spice-server bug fix and enhancement update 2013-11-20 16:39:57 EST

  None (edit)
Description Marc-Andre Lureau 2013-04-24 14:22:43 EDT
Description of problem:

Server aborts after second seamless migration in display_channel_client_restore_surface()

spice-server-0.12.0-12.el6.x86_64

How reproducible:
90% with my setup

Steps to Reproduce:
1. run 3 (or more) instances of qemu with a windows guest, using qxl driver, configured for seamless migration
2. connect to first instance with a spice-gtk based client that supports seamless migration (rhevm 3.2 mingw-virt-viewer or upstream spice-gtk)
3. while keeping client connected, do migrations between qemu instance


Actual results:
spice server crash

#0  0x00007fac728ac54d in read () from /lib64/libpthread.so.0
#1  0x00007fac71100c20 in read () at /usr/include/bits/unistd.h:45
#2  spice_backtrace_gstack () at backtrace.c:100
#3  0x00007fac71108d50 in spice_logv (log_domain=0x7fac71184f3c "SpiceWorker", log_level=SPICE_LOG_LEVEL_ERROR, strloc=0x7fac71185728 "red_worker.c:9772", function=0x7fac71187d80 "display_channel_client_restore_surface", format=0x7fac7117fd58 "assertion `%s' failed", args=0x7fac611fa920) at log.c:108
#4  0x00007fac71108e8a in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, format=<value optimized out>) at log.c:123
#5  0x00007fac710cf25e in display_channel_client_restore_surface (rcc=0x7fac68622010, size=<value optimized out>, message=<value optimized out>) at red_worker.c:9772
#6  display_channel_client_restore_surfaces_lossless (rcc=0x7fac68622010, size=<value optimized out>, message=<value optimized out>) at red_worker.c:9785


Expected results:

no crash during migration

Additional info:

seems like whether migrated surfaces are lossy or not make a difference. I am running the client over a poor wifi LAN at home.
Comment 1 Marc-Andre Lureau 2013-04-24 14:24:30 EDT
as a temporary solution, replacing the assert() with a warn() seems quite harmless... the server keeps running fine.

Imho, the server should never crash, even if client sends corrupted data.
Comment 2 Yonit Halperin 2013-04-24 17:20:53 EDT
Marc-Andre,
I'm not able to reproduce it with my setup.
Please attach your qemu command line. The qemu src and dst logs, and the remote-viewer log (all with the highest debug level), may also be helpful.
Comment 3 Marc-Andre Lureau 2013-04-25 07:38:56 EDT
sent patch to ML:
http://lists.freedesktop.org/archives/spice-devel/2013-April/013200.html
Comment 12 errata-xmlrpc 2013-11-21 02:41:26 EST
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

Note You need to log in before you can comment on or make changes to this bug.