Red Hat Bugzilla – Bug 868807
Qemu aborted when change the resolution of guest from 1024x768 to 2560x1600
Last modified: 2013-07-03 08:11:38 EDT
Description of problem: Qemu aborted when change the resolution of guest from 1024x768 to 2560x1600. Version-Release number of selected component (if applicable): host info: # uname -r && rpm -q qemu-kvm 2.6.32-331.el6.x86_64 qemu-kvm-0.12.1.2-2.327.el6.x86_64 # rpm -qa | grep virt-viewer virt-viewer-0.5.2-14.el6.x86_64 # rpm -qa | grep spice-gtk spice-gtk-tools-0.14-4.el6.x86_64 spice-gtk-python-0.14-4.el6.x86_64 spice-gtk-debuginfo-0.14-4.el6.x86_64 spice-gtk-0.14-4.el6.x86_64 guest info: # uname -r 2.6.32-331.el6.x86_64 How reproducible: hit twice time Steps to Reproduce: 1.boot guest with '-spice port=5931,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.vram_size=67108864'. 2.install virt-viewer package in host, and use 'remote-viewer spice://$host_ip:$port' to connect guest desktop. 3.change the resolution of guest from 1024x768 to 2560x1600. System-->Preferences-Display, select '2560x1600' resolution and hit 'Apply'. Actual results: after step 3, QEMU occur aborted like: (/usr/bin/gdb:24917): SpiceWorker-CRITICAL **: red_worker.c:10916:red_push_monitors_config: condition `monitors_config != NULL' failed Detaching after fork from child process 24947. Program received signal SIGABRT, Aborted. 0x00007ffff574c8a5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff574c8a5 in raise () from /lib64/libc.so.6 #1 0x00007ffff574e085 in abort () from /lib64/libc.so.6 #2 0x00007ffff5fa5c35 in spice_logv (log_domain=0x7ffff6021d9c "SpiceWorker", log_level=SPICE_LOG_LEVEL_CRITICAL, strloc=0x7ffff60220bd "red_worker.c:10916", function= 0x7ffff6023d90 "red_push_monitors_config", format=0x7ffff60220a7 "condition `%s' failed", args=0x7fffe5bfb970) at log.c:109 #3 0x00007ffff5fa5d6a in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, format=<value optimized out>) at log.c:123 #4 0x00007ffff5f8390d in on_new_display_channel_client (opaque=<value optimized out>, payload=0x7ffec421d0b0) at red_worker.c:9489 #5 handle_new_display_channel (opaque=<value optimized out>, payload=0x7ffec421d0b0) at red_worker.c:10376 #6 handle_dev_display_connect (opaque=<value optimized out>, payload=0x7ffec421d0b0) at red_worker.c:11216 #7 0x00007ffff5f63cc7 in dispatcher_handle_single_read (dispatcher=0x7ffff8b86c78) at dispatcher.c:139 #8 dispatcher_handle_recv_read (dispatcher=0x7ffff8b86c78) at dispatcher.c:162 #9 0x00007ffff5f8488e in red_worker_main (arg=<value optimized out>) at red_worker.c:11782 #10 0x00007ffff7740851 in start_thread () from /lib64/libpthread.so.0 #11 0x00007ffff580167d in clone () from /lib64/libc.so.6 (gdb) Expected results: QEMU/geust should work well after change the resolution of guest without aborted . Additional info: I also hit this issue when I change the guest'resolution after migration, qemu also aborted.
(In reply to comment #0) > > Steps to Reproduce: > 1.boot guest with '-spice port=5931,disable-ticketing,seamless-migration=on > -vga qxl -global qxl-vga.vram_size=67108864'. > 2.install virt-viewer package in host, and use 'remote-viewer > spice://$host_ip:$port' to connect guest desktop. This is my mistake of description, I have install the virt-viewer package in advance exactly. My host cpu info: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 6784.25 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
I have been trying to reproduce unsuccesfully atm: while true ; do sleep 1 && xrandr --output qxl-0 --mode 640x480 && sleep 1 && xrandr --output qxl-0 --mode 2560x1600 ; done
(In reply to comment #4) > I have been trying to reproduce unsuccesfully atm: while true ; do sleep 1 > && xrandr --output qxl-0 --mode 640x480 && sleep 1 && xrandr --output qxl-0 > --mode 2560x1600 ; done As comment #0, i hit two times. I remember that hit this issue when i run on SandyBridge host, not sure other host, maybe it's not very hard to reproduce it as comment #0. Best Regards. sluo
I could not reproduce either on a 6.4 host/6.4 client and a rhel6 guest (not 6.4).
No action, devel can't reproduce it (see comments 4, 6). propose for 6.5, and low severity
*** Bug 882407 has been marked as a duplicate of this bug. ***
Another way to reproduce (from duplicate bug 882407): 1. Connect to the guest using remote viewer client. 2. Forcefully poweroff the client machine with spice session opened. 3. Reconnect from different client machine or from the same machine after booting it up.
I am not sure It's the same problem, anyway proposing back for 6.4 since I can reproduce easily.
(In reply to comment #11) > I am not sure It's the same problem, anyway proposing back for 6.4 since I > can reproduce easily. ok, thanks. I remember that I can also hit this issue when I change the guest'resolution after migration, qemu will the same aborted.
I can't reproduce this bug (tried both ways). I'm running RHEL-6.4 (pre) for host, guest and (a VM) client.
Fixed by Hans upstream: http://lists.freedesktop.org/archives/spice-devel/2013-January/011997.html
(In reply to comment #14) > Fixed by Hans upstream: > http://lists.freedesktop.org/archives/spice-devel/2013-January/011997.html Hans! Wonderful! Let's not wait too long for the build.
(In reply to comment #14) > Fixed by Hans upstream: > http://lists.freedesktop.org/archives/spice-devel/2013-January/011997.html Maybe, maybe, I accidentally during testing hit this assert, and I luckily always run qemu under a debugger and hit it once, so I could figure out what was going on *in my case*. And my patch fixes this. This cause is likely the same as the cause of this bug. So what we can do for 6.4 is add my patch to spice-server, as it fixes a real issue, and likely the issue this bug describes. However I cannot guarantee that this will fix the issue Marian is seeing, if Marian can still reproduce with my patch added we will need to move this to 6.5 . With that said: devel-ack.
This is fixed in spice-server-0.12.0-12.el6, moving to modified
When trying to reproduce on -11 using Uri's reproducer from comment 10 (with slight modification, use ip(6)tables ... --dport PORT -j DROP, close client, then connect from different machine), I triggered this assertion: > qemu-kvm: marshaller.c:165: spice_marshaller_reset: Assertion `m->data->marshallers == m' failed. May that be caused possile memory corruption fixed in patch 2/2? [1] from patch 2/2: > 2) The code is wrong, as it allocs space for real_count heads, where > real_count always <= monitors_config->count and then stores > monitors_config->count in worker->monitors_config->count, causing > red_marshall_monitors_config to potentially walk > worker->monitors_config->heads past its boundaries. I couldn't reproduce anymore in more than 10 subsequent tries, so I'm not sure that negative result with fixed spice-server will be really telling something...
(In reply to comment #19) > When trying to reproduce on -11 using Uri's reproducer from comment 10 (with > slight modification, use ip(6)tables ... --dport PORT -j DROP, close client, > then connect from different machine), I triggered this assertion: > > > qemu-kvm: marshaller.c:165: spice_marshaller_reset: Assertion `m->data->marshallers == m' failed. > > May that be caused possile memory corruption fixed in patch 2/2? That is highly unlikely as: 1) That is a read only out of bands addressing 2) It only happens with sparse monitor configs It seems that is just a completely unrelated issue. When reproducing this bug, the (un)expected result should be: "SpiceWorker-CRITICAL **: red_worker.c:10916:red_push_monitors_config: condition `monitors_config != NULL' failed" Maybe Marian can still reproduce it using his reproducer. Note that reproducing it is timing dependent and likely also host cpu and network load dependent...
Adding SanityOnly as I can't reproduce neither on affected, nor on fixed version.
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-2013-0529.html