Bug 83284

I use also the kernel 3.16.1, mesa 10.2.6-2, xorg-server 1.16.0-6

I can't manage to reproduce. Can you provide a qemu backtrace when the crash happens? thanks a lot

(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 ?

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

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

(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.

(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.

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

Same comment as comment #5
I assume you don't have this patch applied, and that you are using spicec?

Fairly sure this is fixed upstream, closing.

(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

bug is still here in qemu 2.3.0

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,

(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

I did the tests with remote-viewer, all is ok,

so this bug is solved