Bug 83284 - qemu crash if I reboot a windows guest when "past / copy clipboard" function is enabled ( vd_agent )
Summary: qemu crash if I reboot a windows guest when "past / copy clipboard" function ...
Status: RESOLVED FIXED
Alias: None
Product: Spice
Classification: Unclassified
Component: server (show other bugs)
Version: unspecified
Hardware: Other All
: high critical
Assignee: Spice Bug List
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-30 21:57 UTC by Barto
Modified: 2015-06-21 21:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Barto 2014-08-30 21:57:08 UTC 
I use archlinux 64 bits as OS host, and qemu 2.1.0-2,

with qemu I run a windows XP and Windows 7 32 bits virtual machines with spice windows drivers from the last official spice drivers package ( spice-guest-tools-0.74.exe ),

I notice if I enable the "past copy" function from spice then I get a weird behaviour :

--> all is ok ( past copy between host and guest works ) as long I don't reboot the virtual machine ( for example if I shutdown the virtual machine, and then if I start immediately the virtual machine there is no problem )

--> but If I select "reboot/restart" in the virtual machine ( windows XP/7 menu "reboot" ) then I get a blue screen of death ( BSOD ) on the next boot of windows XP/7

the error in systemd log :

qemu-system-x86[2230]: segfault at 0 ip 00007f26904eca1b sp 00007fff02c2fd90 error 4 in libspice-server.so.1.9.0[7f26904e0000+11e000]

my qemu script :

export SPICE_PORT=5924
export QEMU_AUDIO_DRV=alsa
export QEMU_AUDIO_DAC_FIXED_FREQ=48000
export QEMU_AUDIO_ADC_FIXED_FREQ=48000 

qemu-system-x86_64 \
-m 1024 -vga  qxl -spice port=5930,disable-ticketing \
-cpu host -enable-kvm  -machine type=pc,accel=kvm -smp 2 \
-soundhw es1370 \
-drive file="Windows XP.vdi",if=virtio \
-netdev user,id=vmnic,hostname=arch-qemu -device virtio-net,netdev=vmnic \
-localtime -daemonize -usbdevice tablet -k fr \
-monitor telnet:localhost:12997,server,nowait,ipv4 \
-device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent


spicec -h 127.0.0.1 -p 5930 --hotkeys release-cursor=ctrl+alt

the same problem occurs with a windows 7 32 bits virtual machine with the same settings,

it's seem that rebooting a virtual machine ( windows guest ) who has the "past copy spice function" enabled is not possible when I use the drivers from spice-guest-tools-0.74.exe,

if I want to avoid the bug then I must shutdown the virtual machine and then booting the virtual machine instead of using the reboot menu of the virtual machine
Comment 1 Barto 2014-08-30 21:58:50 UTC 
I use also the kernel 3.16.1, mesa 10.2.6-2, xorg-server 1.16.0-6
Comment 2 Marc-Andre Lureau 2014-10-27 09:55:58 UTC 
I can't manage to reproduce. Can you provide a qemu backtrace when the crash happens? thanks a lot
Comment 3 Barto 2014-10-27 19:48:12 UTC 
(In reply to Marc-Andre Lureau from comment #2)
> I can't manage to reproduce. Can you provide a qemu backtrace when the crash
> happens? thanks a lot

I can easily reproduce this bug,

very important: you have to use a rolling release linux distribution ( like archlinux in order to have the latest version of system packages, like the kernel, xorg server ) and exactly the same settings I use,

I use archlinux 64 bits, kernel 3.17.1-1,qemu 2.1.2-1,

the guest is windows 7 32 bits with spice-guest-tools-0.74.exe,

the qemu script :


export SPICE_PORT=5924
export QEMU_AUDIO_DRV=alsa
export QEMU_AUDIO_DAC_FIXED_FREQ=48000
export QEMU_AUDIO_ADC_FIXED_FREQ=48000 

qemu-system-x86_64 \
-m 1024 -vga  qxl -spice port=5930,disable-ticketing -cpu host -enable-kvm  -machine type=pc,accel=kvm -smp 2 \
-soundhw ac97 \
-drive file="/mnt/wd640/machines virtuelles/win7storage/win7.vdi",if=virtio \
-netdev user,id=vmnic,hostname=arch-qemu -device virtio-net,netdev=vmnic \
-localtime -daemonize -usbdevice tablet -k fr \
-monitor telnet:127.0.0.1:12997,server,nowait,ipv4 \
-device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent


spicec -h 127.0.0.1 -p 5930 --hotkeys release-cursor=ctrl+alt

if I try to reboot I get a crash :

qemu-system-x86[1067]: segfault at 0 ip 00007f82e2a80a1b sp 00007ffff2423440 error 4 in libspice-server.so.1.9.0[7f82e2a74000+11e000]


how to use gdb with my qemu script in order to have a backtrace ?
Comment 4 Barto 2014-10-27 20:13:12 UTC 
I have also the same problem if I use a linux guest OS ( archlinux 32 bits ) and if a virtserialport device is enabled in order to have the feature "past/copy" between the host and the guest,

the "past/copy" feature works, but if I try to reboot the guest ( via the menu "reboot" from the guest ) a crash will occur :

qemu-system-x86[2230]: segfault at 0 ip 00007f26904eca1b sp 00007fff02c2fd90 error 4 in libspice-server.so.1.9.0[7f26904e0000+11e000]

If I just "shutdown" the guest OS ( via the appropriate menu ) then there is no crash, all is ok,

so the crash occurs only during the reboot process, it's seems that something will be broken ( a link related to the virtserialport ? )  when qemu tries to reboot the guest OS, a bug about virtserialport who is triggered when the reboot process occurs
Comment 5 Christophe Fergeau 2014-10-28 10:06:19 UTC 
As you are using spicec which does not expose SPICE_MAIN_CAP_AGENT_CONNECTED_TOKENS , it's very likely to be fixed by http://cgit.freedesktop.org/spice/spice/commit/?id=4639817f0eb26316894cc83b43a736bdd72f9018

Using remote-viewer is highly recommended though.

Regarding your question as to how to get a bactrace with your qemu script, I'd start the script as usual, and then run
gdb --pid $(pidof qemu-system-x86_64)
Type 'c' (or 'continue') at the gdb prompt
Then reboot your VM, and when it crashes, go back to gdb, and type "thread apply all bt"
You can exit gdb with 'exit' or ctrl+d
Comment 6 Barto 2014-10-28 18:43:25 UTC 
(In reply to Christophe Fergeau from comment #5)
> As you are using spicec which does not expose
> SPICE_MAIN_CAP_AGENT_CONNECTED_TOKENS , it's very likely to be fixed by
> http://cgit.freedesktop.org/spice/spice/commit/
> ?id=4639817f0eb26316894cc83b43a736bdd72f9018
> 
> Using remote-viewer is highly recommended though.
> 


what is "remote-viewer" ?

I hope your patch will be included in the next official version of spice



> Regarding your question as to how to get a bactrace with your qemu script,
> I'd start the script as usual, and then run
> gdb --pid $(pidof qemu-system-x86_64)
> Type 'c' (or 'continue') at the gdb prompt
> Then reboot your VM, and when it crashes, go back to gdb, and type "thread
> apply all bt"
> You can exit gdb with 'exit' or ctrl+d

I tried with :

"gdb --pid 4687" but I get an error message from gdb :

Attaching to process 4687
ptrace: Opération non permise.
Comment 7 Christophe Fergeau 2014-10-29 09:20:05 UTC 
(In reply to Barto from comment #6)
> (In reply to Christophe Fergeau from comment #5)
> > As you are using spicec which does not expose
> > SPICE_MAIN_CAP_AGENT_CONNECTED_TOKENS , it's very likely to be fixed by
> > http://cgit.freedesktop.org/spice/spice/commit/
> > ?id=4639817f0eb26316894cc83b43a736bdd72f9018
> > 
> > Using remote-viewer is highly recommended though.
> > 
> 
> 
> what is "remote-viewer" ?

It's a newer gtk+ spice client. It's part of the 'virt-viewer' package https://fedorahosted.org/released/virt-viewer/


> I hope your patch will be included in the next official version of spice

It's in spice git repository so will be in the next release of spice-server.

> > Regarding your question as to how to get a bactrace with your qemu script,
> > I'd start the script as usual, and then run
> > gdb --pid $(pidof qemu-system-x86_64)
> > Type 'c' (or 'continue') at the gdb prompt
> > Then reboot your VM, and when it crashes, go back to gdb, and type "thread
> > apply all bt"
> > You can exit gdb with 'exit' or ctrl+d
> 
> I tried with :
> 
> "gdb --pid 4687" but I get an error message from gdb :
> 
> Attaching to process 4687
> ptrace: Opération non permise.

Ah you might need to run this as root if qemu is not running as the same user as gdb.
Comment 8 Darin McBride 2015-04-15 22:40:13 UTC 
I keep having much of this problem, found this bug, and could reproduce it in gdb.  I hope this trace can help.

I'm running on Gentoo x86_64, Win7 guest.  I've been having this problem for a while, but didn't think to look in the system logs for qemu up until now.  Currently 3.19.2 kernel, 10.4.4 mesa, nvidia drivers, etc.

I don't get BSOD on next boot, but rebooting doesn't work.  Win7 also dies all on its own from time to time, I wonder if it's related, so I'm going to leave it running under gdb for a while to see.  Anyway, for the reboot issue:

Program received signal SIGSEGV, Segmentation fault.
0x00007f631fdbea11 in spice_char_device_write_to_device (
    dev=dev@entry=0x7f6324f491e0) at char_device.c:443
443     char_device.c: No such file or directory.
(gdb) thread apply all bt

Thread 6 (Thread 0x7f631b2f2700 (LWP 19485)):
#0  sem_timedwait () at ../sysdeps/unix/sysv/linux/x86_64/sem_timedwait.S:101
#1  0x00007f632368ce7f in qemu_sem_timedwait (sem=sem@entry=0x7f6324cf5618, 
    ms=ms@entry=10000)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/util/qemu-thread-posix.c:257
#2  0x00007f63235eb3fc in worker_thread (opaque=0x7f6324cf55b0)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/thread-pool.c:92
#3  0x00007f6320ac1224 in start_thread (arg=0x7f631b2f2700)
    at pthread_create.c:310
#4  0x00007f631f3e55ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7f631a70e700 (LWP 19486)):
#0  pthread_cond_wait ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f632368cc99 in qemu_cond_wait (cond=<optimized out>, 
    mutex=mutex@entry=0x7f6323b4ff40 <qemu_global_mutex>)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/util/qemu-thread-posix.c:135
#2  0x00007f632331455a in qemu_kvm_wait_io_event (cpu=<optimized out>)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/cpus.c:926
#3  qemu_kvm_cpu_thread_fn (arg=0x7f6324e619d0)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/cpus.c:962
#4  0x00007f6320ac1224 in start_thread (arg=0x7f631a70e700)
    at pthread_create.c:310
#5  0x00007f631f3e55ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7f6319f0d700 (LWP 19487)):
#0  pthread_cond_wait ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f632368cc99 in qemu_cond_wait (cond=<optimized out>, 
    mutex=mutex@entry=0x7f6323b4ff40 <qemu_global_mutex>)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/util/qemu-thread-posix.c:135
#2  0x00007f632331455a in qemu_kvm_wait_io_event (cpu=<optimized out>)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/cpus.c:926
#3  qemu_kvm_cpu_thread_fn (arg=0x7f6324e9ec50)
---Type <return> to continue, or q <return> to quit---
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/cpus.c:962
#4  0x00007f6320ac1224 in start_thread (arg=0x7f6319f0d700)
    at pthread_create.c:310
#5  0x00007f631f3e55ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7f63191ff700 (LWP 19488)):
#0  0x00007f631f3dc99d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f631fe05423 in poll (__timeout=<optimized out>, __nfds=20, 
    __fds=0x7f61fc0008f8) at /usr/include/bits/poll2.h:46
#2  red_worker_main (arg=<optimized out>) at red_worker.c:11994
#3  0x00007f6320ac1224 in start_thread (arg=0x7f63191ff700)
    at pthread_create.c:310
#4  0x00007f631f3e55ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f6203fff700 (LWP 19490)):
#0  0x00007f631f3dc99d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f631fbaad54 in poll (__timeout=-1, __nfds=2, __fds=0x7f6203ffec60)
    at /usr/include/bits/poll2.h:46
#2  linux_udev_event_thread_main (arg=<optimized out>)
    at /var/tmp/portage/dev-libs/libusb-1.0.19/work/libusb-1.0.19/libusb/os/linux_udev.c:176
#3  0x00007f6320ac1224 in start_thread (arg=0x7f6203fff700)
    at pthread_create.c:310
#4  0x00007f631f3e55ed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7f63231d29c0 (LWP 19484)):
#0  0x00007f631fdbea11 in spice_char_device_write_to_device (
    dev=dev@entry=0x7f6324f491e0) at char_device.c:443
#1  0x00007f631fdbf947 in spice_char_device_write_to_device (dev=<optimized out>)
    at char_device.c:436
#2  spice_char_device_start (dev=0x7f6324f491e0) at char_device.c:798
#3  0x00007f631fe11709 in spice_server_vm_start (s=<optimized out>)
    at reds.c:3795
#4  0x00007f63234abf23 in device_reset (dev=0x7f6324f0df10)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/hw/core/qdev.c:1223
#5  qdev_reset_one (opaque=0x0, dev=0x7f6324f0df10)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/hw/core/qdev.c---Type <return> to continue, or q <return> to quit---
:279
#6  qdev_walk_children (pre_devfn=0x0, pre_busfn=0x0, 
    post_devfn=0x7f63234abe00 <qdev_reset_one>, 
    post_busfn=0x7f63234aac10 <qbus_reset_one>, opaque=0x0, dev=0x7f6324f0df10)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/hw/core/qdev.c:593
#7  qbus_walk_children (bus=bus@entry=0x7f6324cd26a0, opaque=0x0, 
    post_busfn=0x7f63234aac10 <qbus_reset_one>, 
    post_devfn=0x7f63234abe00 <qdev_reset_one>, pre_busfn=0x0, pre_devfn=0x0)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/hw/core/qdev.c:551
#8  0x00007f63234abec1 in qdev_walk_children (pre_devfn=0x0, pre_busfn=0x0, 
    post_devfn=0x7f63234abe00 <qdev_reset_one>, 
    post_busfn=0x7f63234aac10 <qbus_reset_one>, opaque=0x0, dev=0x7f6324cd0db0)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/hw/core/qdev.c:585
#9  qbus_walk_children (bus=0x7f6324e61390, opaque=0x0, 
    post_busfn=0x7f63234aac10 <qbus_reset_one>, 
    post_devfn=0x7f63234abe00 <qdev_reset_one>, pre_busfn=0x0, pre_devfn=0x0)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/hw/core/qdev.c:551
#10 0x00007f63232db07d in qemu_devices_reset ()
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/vl.c:1702
#11 qemu_system_reset (report=true)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/vl.c:1715
#12 main_loop_should_exit ()
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/vl.c:1846
#13 main_loop ()
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/vl.c:1886
#14 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
    at /var/tmp/portage/app-emulation/qemu-2.2.1-r1/work/qemu-2.2.1/vl.c:4401
Comment 9 Christophe Fergeau 2015-04-16 12:09:49 UTC 
Same comment as comment #5
I assume you don't have this patch applied, and that you are using spicec?
Comment 10 Christophe Fergeau 2015-06-17 13:18:37 UTC 
Fairly sure this is fixed upstream, closing.
Comment 11 Barto 2015-06-19 16:56:16 UTC 
(In reply to Christophe Fergeau from comment #10)
> Fairly sure this is fixed upstream, closing.


sorry but I still have the bug with qemu 2.3.0, if I reboot a windows 7 32 bits guest I have this error message in archlinux host :

(/usr/bin/spicec:2197): Spice-Warning **: red_peer.cpp:304:receive: Connexion ré-initialisée par le correspondant (104)
Warning: Connexion ré-initialisée par le correspondant (104)

for me the bug is not solved, you should reopen this bugreport
Comment 12 Barto 2015-06-19 16:57:01 UTC 
bug is still here in qemu 2.3.0
Comment 13 Victor Toso 2015-06-19 17:10:50 UTC 
Hey,

(In reply to Barto from comment #11)
> (In reply to Christophe Fergeau from comment #10)
> > Fairly sure this is fixed upstream, closing.
> 
> 
> sorry but I still have the bug with qemu 2.3.0, if I reboot a windows 7 32
> bits guest I have this error message in archlinux host :
> 
> (/usr/bin/spicec:2197): Spice-Warning **: red_peer.cpp:304:receive:
> Connexion ré-initialisée par le correspondant (104)
> Warning: Connexion ré-initialisée par le correspondant (104)
> 
> for me the bug is not solved, you should reopen this bugreport

spicec is deprecated client, could you please try with remote-viewer (inside virt-viewer package) to see if comment #5 solves your problem?

Also, please add `gdb --args` before qemu-system-x86_64 in your script so we could verify the backtrace with remote-viewer as well.

Thanks,
Comment 14 Barto 2015-06-20 11:43:10 UTC 
(In reply to Victor Toso from comment #13)
> spicec is deprecated client, could you please try with remote-viewer (inside
> virt-viewer package) to see if comment #5 solves your problem?
> 
> Also, please add `gdb --args` before qemu-system-x86_64 in your script so we
> could verify the backtrace with remote-viewer as well.
> 
> Thanks,

Ok I will try, I will post the results later
Comment 15 Barto 2015-06-21 21:31:25 UTC 
I did the tests with remote-viewer, all is ok,

so this bug is solved

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.