RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1028637 - i686 client gets segfault at repeated migration
Summary: i686 client gets segfault at repeated migration
Keywords:
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:
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)

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
Clone Of:
Environment:
Last Closed: 2014-10-14 06:46:41 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1487 0 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.