Bug 1028637 - i686 client gets segfault at repeated migration
i686 client gets segfault at repeated migration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk (Show other bugs)
6.5
i686 Unspecified
high Severity high
: rc
: ---
Assigned To: Default Assignee for SPICE Bugs
Desktop QE
: ZStream
Depends On:
Blocks: 1007841 1090001
  Show dependency treegraph
 
Reported: 2013-11-08 18:29 EST by David Jaša
Modified: 2014-10-14 02:46 EDT (History)
8 users (show)

See Also:
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 02:46:41 EDT
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)
gdb output (21.44 KB, text/plain)
2013-11-11 08:32 EST, David Jaša
no flags Details

  None (edit)
Description David Jaša 2013-11-08 18:29:41 EST
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-08 19:38:53 EST
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 08:32:22 EST
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 08:35:09 EST
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 08:50:02 EST
(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 13:43:22 EST
(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 16:22:48 EST
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 10:57:10 EST
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 09:46:02 EST
This is actually fixed by http://lists.freedesktop.org/archives/spice-devel/2013-September/014520.html
Comment 9 Marc-Andre Lureau 2014-04-16 09:29:25 EDT
zstream update?
Comment 13 errata-xmlrpc 2014-10-14 02:46: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-2014-1487.html

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