Bug 1028637 - i686 client gets segfault at repeated migration
Summary: i686 client gets segfault at repeated migration
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk
Version: 6.5
Hardware: i686
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords: ZStream
Depends On:
Blocks: 1007841 1090001
TreeView+ depends on / blocked
 
Reported: 2013-11-08 23:29 UTC by David Jaša
Modified: 2014-10-14 06:46 UTC (History)
8 users (show)

(edit)
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
Clone Of:
(edit)
Last Closed: 2014-10-14 06:46:41 UTC


Attachments (Terms of Use)
gdb output (21.44 KB, text/plain)
2013-11-11 13:32 UTC, David Jaša
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1487 normal SHIPPED_LIVE spice-gtk bug fix and enhancement update 2014-10-14 01:28:31 UTC

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


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