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 868807 - Qemu aborted when change the resolution of guest from 1024x768 to 2560x1600
Summary: Qemu aborted when change the resolution of guest from 1024x768 to 2560x1600
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-server
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Hans de Goede
QA Contact: Desktop QE
URL:
Whiteboard:
: 882407 (view as bug list)
Depends On:
Blocks: 902691
TreeView+ depends on / blocked
 
Reported: 2012-10-22 08:14 UTC by Sibiao Luo
Modified: 2013-07-03 12:11 UTC (History)
23 users (show)

Fixed In Version: spice-server-0.12.0-12.el6
Doc Type: Bug Fix
Doc Text:
No documentation is required. This bug is related to a arbitrary-resolution feature new in RHEL-6.4. It was found (in the meaning of "created") and fixed during RHEL-6.4 development phase.
Clone Of:
Environment:
Last Closed: 2013-02-21 10:03:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0529 0 normal SHIPPED_LIVE spice-server bug fix and enhancement update 2013-02-20 21:51:04 UTC

Description Sibiao Luo 2012-10-22 08:14:17 UTC 
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.
Comment 1 Sibiao Luo 2012-10-22 08:18:19 UTC 
(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:
Comment 4 Marc-Andre Lureau 2012-11-15 18:46:33 UTC 
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
Comment 5 Sibiao Luo 2012-11-16 02:50:13 UTC 
(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
Comment 6 Christophe Fergeau 2012-11-28 17:50:57 UTC 
I could not reproduce either on a 6.4 host/6.4 client and a rhel6 guest (not 6.4).
Comment 7 David Blechter 2012-11-28 17:57:04 UTC 
No action, devel can't reproduce it (see comments 4, 6).
propose for 6.5, and low severity
Comment 9 Uri Lublin 2012-12-02 10:50:25 UTC 
*** Bug 882407 has been marked as a duplicate of this bug. ***
Comment 10 Uri Lublin 2012-12-02 10:53:09 UTC 
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.
Comment 11 Marian Krcmarik 2012-12-02 13:16:30 UTC 
I am not sure It's the same problem, anyway proposing back for 6.4 since I can reproduce easily.
Comment 12 Sibiao Luo 2012-12-03 01:43:20 UTC 
(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.
Comment 13 Uri Lublin 2012-12-06 14:49:02 UTC 
I can't reproduce this bug (tried both ways).
I'm running RHEL-6.4 (pre) for host, guest and (a VM) client.
Comment 14 Uri Lublin 2013-01-14 18:12:54 UTC 
Fixed by Hans upstream:
http://lists.freedesktop.org/archives/spice-devel/2013-January/011997.html
Comment 15 Marian Krcmarik 2013-01-14 18:17:44 UTC 
(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.
Comment 16 Hans de Goede 2013-01-15 13:37:18 UTC 
(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.
Comment 17 Hans de Goede 2013-01-16 10:18:01 UTC 
This is fixed in spice-server-0.12.0-12.el6, moving to modified
Comment 19 David Jaša 2013-01-17 15:41:09 UTC 
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...
Comment 20 Hans de Goede 2013-01-18 14:46:57 UTC 
(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...
Comment 21 David Jaša 2013-01-23 13:58:45 UTC 
Adding SanityOnly as I can't reproduce neither on affected, nor on fixed version.
Comment 24 errata-xmlrpc 2013-02-21 10:03:43 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-2013-0529.html
Note You need to log in before you can comment on or make changes to this bug.