Bug 1028637

Summary: i686 client gets segfault at repeated migration
Product: Red Hat Enterprise Linux 6 Reporter: David Jaša <djasa>
Component: spice-gtkAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.5CC: cfergeau, dblechte, djasa, jjongsma, marcandre.lureau, mkrcmari, rbalakri, tlavigne
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard:
Fixed In Version: spice-gtk-0.22-1.el6 Doc Type: Bug Fix
Doc Text:
When migrating a guest repeatedly while connected to the guest with a i686 client, the client can crash. After fixing the bug, the client will no longer crash during migration
 Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-14 06:46:41 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: 1007841, 1090001    
Attachments:
Description Flags
gdb output none

Description David Jaša 2013-11-08 23:29:41 UTC 
Description of problem:
When doing repeated migrations with i686 client connected, client segfaults in a way that gdb can't produce backtrace (Cannot access memory at 0x...).

Version-Release number of selected component (if applicable):
virt-viewer-0.5.6-8.el6.i686
spice-gtk-0.20-11.el6.i686

How reproducible:
always (at least on my machine)

Steps to Reproduce:
1. connect to a RHEV VM
2. do repeated migrations of the VM (you can use bash commands below).
3.

Actual results:
client gets segfault

Expected results:


Additional info:
I'll attach coredump & binary image next week. I could also try to run client under valgrind.

Bash commands to automate migrations:
mkdir .rhevm
wget -O .rhevm/rhevm.pem http://rhevm.example.org/ca.crt
curl -H "prefer: persistent-auth" -b .rhevm/cookie-admin -c .rhevm/cookie-admin  --cacert .rhevm/rhevm.pem https://rhevm.example.org/api -u admin@internal
while ps $REMOTE_VIEWER_PID > /dev/null ; curl -D - -H "Content-type: application/xml" -H "prefer: persistent-auth" -b .rhevm/cookie-admin -c .rhevm/cookie-admin  --cacert .rhevm/rhevm.pem https://rhevm.example.org/api/vms/VM_UUID/migrate -X POST -d '<action/>' ; do sleep 20 ; done
Comment 1 Marc-Andre Lureau 2013-11-09 00:38:53 UTC 
woot? gdb can't access memory? Could you get that gdb log please?

Can you reproduce without using rhevm?

thanks
Comment 2 David Jaša 2013-11-11 13:32:22 UTC 
Created attachment 822406 [details]
gdb output

gdb remote-viewer --ex "<...>" will give you the same results but with a bit of bad luck, it will eat your keyboard after the crash.
Comment 3 David Jaša 2013-11-11 13:35:09 UTC 
Created attachment 822407 [details]
valgrind ... remote-viewer ... --spice-debug

here is debug output captured under valgrind: based on what valgrind says, r-v tries to read address 0x1 just after spice-gtk prints "Open coroutine starting 0x478c7e0"
Comment 4 David Jaša 2013-11-11 13:50:02 UTC 
(In reply to Marc-Andre Lureau from comment #1)
> Can you reproduce without using rhevm?

Not in near time frame. Hopefully the manual client invocation above will suffice.
Comment 5 Marc-Andre Lureau 2013-11-13 18:43:22 UTC 
(In reply to David Jaša from comment #2)
> Created attachment 822406 [details]
> gdb output
> 
> gdb remote-viewer --ex "<...>" will give you the same results but with a bit
> of bad luck, it will eat your keyboard after the crash.

that's because the process is still around for gdb to give backtrace etc, so X doesn't release the grab. You should run SPICE_NOGRAB=1 when running under gdb.
Comment 6 Marc-Andre Lureau 2013-11-13 21:22:48 UTC 
I couldn't reproduce using f19 qemu/spice and RHEL6 remote-viewer. 

I am using the following script
https://gist.github.com/elmarco/7456234

Do you think you could extend the script until we have a reproducer?
Comment 7 Christophe Fergeau 2013-11-14 15:57:10 UTC 
I've been able to reproduce using djasa's commands and rhel6/f20 i686 packages. No good backtrace either though ;)

The log I managed to get is quite similar to djasa's

(remote-viewer:15083): GSpice-DEBUG: spice-session.c:171 New session (compiled from package spice-gtk 0.21)
(remote-viewer:15083): GSpice-DEBUG: spice-session.c:175 Supported channels: main, display, inputs, cursor, playback, record, smartcard
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:2092 migrate_begin 37 hyper02.spice.lab.eng.brq.redhat.com 5902 5903
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:1953 migrate_channel_connect 1:0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:127 main-1:0: spice_channel_constructed
(remote-viewer:15083): GSpice-DEBUG: spice-session.c:1883 main-1:0: new main channel, switching
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2368 main-1:0: Open coroutine starting 0x860eef0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2214 main-1:0: Started background coroutine 0x860eaa4
(remote-viewer:15083): GSpice-DEBUG: spice-session.c:1696 connecting 0xfeffdcc8...
(remote-viewer:15083): GSpice-DEBUG: spice-session.c:1765 open host hyper02.spice.lab.eng.brq.redhat.com:5902
(remote-viewer:15083): GSpice-DEBUG: spice-session.c:1682 connect ready
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1167 main-1:0: channel type 1 id 0 num common caps 1 num caps 1
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1198 main-1:0: Peer version: 2:2
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1695 main-1:0: spice_channel_recv_link_msg: 2 caps
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1705 main-1:0: got common caps 0:0xB
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1711 main-1:0: got channel caps 0:0x9
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2602 test cap 0 in 0xB: yes
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2602 test cap 2 in 0xB: no
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2602 test cap 1 in 0xB: yes
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2602 test cap 3 in 0xB: yes
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1740 main-1:0: use mini header: 1
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:1953 migrate_channel_connect 3:0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:127 inputs-3:0: spice_channel_constructed
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:1953 migrate_channel_connect 2:0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:127 display-2:0: spice_channel_constructed
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:1953 migrate_channel_connect 4:0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:127 cursor-4:0: spice_channel_constructed
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:1953 migrate_channel_connect 5:0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:127 playback-5:0: spice_channel_constructed
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:1953 migrate_channel_connect 6:0
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:127 record-6:0: spice_channel_constructed
(remote-viewer:15083): GSpice-DEBUG: channel-main.c:2025 migration: channel opened chan:0x860eef0, left 6
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2602 test cap 3 in 0x9: yes
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:1104 main-1:0: channel up, state 5
(remote-viewer:15083): GSpice-DEBUG: spice-channel.c:2368 inputs-3:0: Open coroutine starting 0x816a7b0
Comment 8 Christophe Fergeau 2013-11-18 14:46:02 UTC 
This is actually fixed by http://lists.freedesktop.org/archives/spice-devel/2013-September/014520.html
Comment 9 Marc-Andre Lureau 2014-04-16 13:29:25 UTC 
zstream update?
Comment 13 errata-xmlrpc 2014-10-14 06:46:41 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-2014-1487.html