Hide Forgot
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
woot? gdb can't access memory? Could you get that gdb log please? Can you reproduce without using rhevm? thanks
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.
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"
(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.
(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.
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?
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
This is actually fixed by http://lists.freedesktop.org/archives/spice-devel/2013-September/014520.html
zstream update?
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