Bug 956345

Summary:	Spice server aborts after 2 seamless migration
Product:	Red Hat Enterprise Linux 6	Reporter:	Marc-Andre Lureau <marcandre.lureau>
Component:	spice-server	Assignee:	Uri Lublin <uril>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	6.4	CC:	acathrow, cfergeau, dblechte, djasa, mkenneth, mkrcmari, yhalperi
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 07:41:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	961427

Description Marc-Andre Lureau 2013-04-24 18:22:43 UTC

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 18:24:30 UTC

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 21:20:53 UTC

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 11:38:56 UTC

sent patch to ML:
http://lists.freedesktop.org/archives/spice-devel/2013-April/013200.html

Comment 12 errata-xmlrpc 2013-11-21 07:41:26 UTC

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