Description of problem: This seems to be a regression, it was working reliably. It's a crash when starting up or changing display size in an Ubuntu 16.10 guest if running with -vga qxl Version-Release number of selected component (if applicable): qemu-system-x86-core-2.9.0-0.2.rc3.fc26 How reproducible: 100% Steps to Reproduce: 1. qemu-system-x86_64 -m 2048M -M pc,accel=kvm -smp 4 -drive if=none,id=cd,readonly=on,file=ubuntu-16.10-desktop-amd64.iso -device ide-cd,drive=cd -vga qxl 2. Wait for it to boot to the point it asks you 'Try ubuntu' and click the 'try ubuntu button. 3. Wait for the desktop to come up 4. Go to settings and select display size and change to 1440x900 Actual results: Crash either at 3 or after 4 Expected results: A happy desktop Additional info: It's been working fine for ages, so I think it's a regression. https://retrace.fedoraproject.org/faf/reports/1668671/ Thread 7 (Thread 0x7fcd59086700 (LWP 5958)): #0 0x00007fcdf2e4113d in read () at /lib64/libpthread.so.0 #1 0x00007fcdf4816ff9 in spice_backtrace_gstack () at /lib64/libspice-server.so.1 #2 0x00007fcdf481e6ef in spice_log () at /lib64/libspice-server.so.1 #3 0x00007fcdf47ec51d in display_channel_update () at /lib64/libspice-server.so.1 #4 0x00007fcdf47e4b06 in handle_dev_update_async () at /lib64/libspice-server.so.1 #5 0x00007fcdf47d9a1d in dispatcher_handle_recv_read () at /lib64/libspice-server.so.1 #6 0x00007fcdf47c4cab in watch_func () at /lib64/libspice-server.so.1 #7 0x00007fcdf6c4d1d7 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #8 0x00007fcdf6c4d578 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #9 0x00007fcdf6c4d892 in g_main_loop_run () at /lib64/libglib-2.0.so.0 #10 0x00007fcdf47e4eaa in red_worker_main () at /lib64/libspice-server.so.1 #11 0x00007fcdf2e3736d in start_thread () at /lib64/libpthread.so.0 #12 0x00007fcdf2b6fe0f in clone () at /lib64/libc.so.6 (gdb) bt full #0 0x00007fc9f06e47bb in raise () at /lib64/libc.so.6 #1 0x00007fc9f06e65d1 in abort () at /lib64/libc.so.6 #2 0x00007fc9f246d6f4 in spice_logv (args=0x7fc956c855f0, format=0x7fc9f24d9132 "condition `%s' failed", function=0x7fc9f24e2290 <__func__.47991> "display_channel_update", strloc=0x7fc9f24e1fc3 "display-channel.c:1757", log_level=SPICE_LOG_LEVEL_CRITICAL, log_domain=0x7fc9f24d8166 "Spice") at log.c:174 log_msg = 0x555aa7bfff00 args = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7fc956c85700, reg_save_area = 0x7fc956c85610}} #3 0x00007fc9f246d6f4 in spice_log (log_domain=log_domain@entry=0x7fc9f24d8166 "Spice", log_level=log_level@entry=SPICE_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7fc9f24e1fc3 "display-channel.c:1757", function=function@entry=0x7fc9f24e2290 <__func__.47991> "display_channel_update", format=format@entry=0x7fc9f24d9132 "condition `%s' failed") at log.c:188 args = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7fc956c85700, reg_save_area = 0x7fc956c85610}} #4 0x00007fc9f243b51d in display_channel_update (display=0x555aa7c4f570, surface_id=0, area=area@entry=0x555aa8ee484c, clear_dirty=1, qxl_dirty_rects=qxl_dirty_rects@entry=0x7fc956c85780, num_dirty_rects=num_dirty_rects@entry=0x7fc956c8577c) at display-channel.c:1757 rect = {left = -1465677888, top = 21850, right = 1455970128, bottom = 32713} __func__ = "display_channel_update" #5 0x00007fc9f2433b06 in handle_dev_update_async (opaque=0x555aa7ac9c60, payload=0x555aa8ee4840) at red-worker.c:430 worker = 0x555aa7ac9c60 msg = 0x555aa8ee4840 qxl_dirty_rects = 0x0 num_dirty_rects = 0 __func__ = "handle_dev_update_async" #6 0x00007fc9f2428a1d in dispatcher_handle_single_read (dispatcher=0x555aa7ba91d0) at dispatcher.c:293 ret = <optimized out> type = 26 msg = 0x555aa7b629f0 ack = 4294967295 payload = 0x555aa8ee4840 "`\214\065\251ZU" #7 0x00007fc9f2428a1d in dispatcher_handle_recv_read (dispatcher=0x555aa7ba91d0) at dispatcher.c:315 #8 0x00007fc9f2413cab in watch_func (source=<optimized out>, condition=<optimized out>, data=0x555aa8c6ac90) at event-loop.c:128 watch = 0x555aa8c6ac90 fd = <optimized out> #9 0x00007fc9f489c1d7 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #10 0x00007fc9f489c578 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #11 0x00007fc9f489c892 in g_main_loop_run () at /lib64/libglib-2.0.so.0 #12 0x00007fc9f2433eaa in red_worker_main (arg=<optimized out>) at red-worker.c:1396 worker = <optimized out> __FUNCTION__ = "red_worker_main" loop = 0x555aa8eea630 #13 0x00007fc9f0a8636d in start_thread () at /lib64/libpthread.so.0 #14 0x00007fc9f07bee0f in clone () at /lib64/libc.so.6
I couldn't reproduce with that exact setup. How reproducible is this for you? I'll be building qemu 2.9.0-rc4 in a minute, please give that a shot, there's a couple qxl crasher fixes though the commit messages don't sound related, but who knows
(In reply to Cole Robinson from comment #1) > I couldn't reproduce with that exact setup. How reproducible is this for you? Hmm, I had it repeat 2 or 3 times in a few minutes - but I've tried it and it's not repeating now doing exactly the same thing (and yum/dnf history is showing me I've not updated either qemu or the spice packages since) > I'll be building qemu 2.9.0-rc4 in a minute, please give that a shot, > there's a couple qxl crasher fixes though the commit messages don't sound > related, but who knows Will do. I wonder if it's a race when it's restarting X/changing res; oh well we'll see if it repeats.
I can also reproduce this, not always, but often, with Kannolo ISOs: https://sourceforge.net/projects/kannolo/files/ I test them using this script: https://svn.calcforge.org/viewvc/kannolo/branches/25/kickstart/test-hdd.sh?revision=176&view=markup It usually happens during shutdown, or the shutdown part of a reboot. So try restarting the ISO a few times, and it will probably happen sooner or later. If I install the ISO to the virtual HDD the above script creates, that installed system behaves the same way. Once, I also had the QEMU crash happen during the bootup of the installed system, I guess it can also happen during the bootup of the live ISO.
I am using: qemu-kvm-2.7.1-6.fc25.x86_64 qemu-system-x86-2.7.1-6.fc25.x86_64
Just triggered what looks like the same case on: qemu-system-x86-core-2.9.0-1.fc26.x86_64 spice-server-0.13.3-2.fc26.x86_64
(In reply to rh from comment #5) > Just triggered what looks like the same case on: > qemu-system-x86-core-2.9.0-1.fc26.x86_64 > spice-server-0.13.3-2.fc26.x86_64 Were you doing anything special at the time of the crash? What was the guest OS?
(In reply to Christophe Fergeau from comment #6) > (In reply to rh from comment #5) > > Just triggered what looks like the same case on: > > qemu-system-x86-core-2.9.0-1.fc26.x86_64 > > spice-server-0.13.3-2.fc26.x86_64 > > Were you doing anything special at the time of the crash? What was the guest > OS? Same as in comment 1 - booted a 16.10 ubuntu ISO, hit the 'Try Ubuntu', and selected to change the guest resolution to 1440x900. This doesn't happen every time, I do this boot maybe once or twice a week and hadn't hit it since April when I opened this. My host was pretty loaded this time.
The host load may have something to do with it. I am using a 2011 desktop computer and a 2008 notebook computer. Both have hardware virtualization, but still, the VM alone puts them under non-negligible load. Especially the 2008 Core 2 Duo.
Still happens with: qemu-system-x86-2.10.1-2.fc27.x86_64
I am running into this on Fedora 27. The error message changes slightly (different source code line number). --- (qemu-system-x86_64:2941): Spice-CRITICAL **: display-channel.c:2035:display_channel_update: condition `display_channel_validate_surface(display, surface_id)' failed --- I don't know how to reproduce this. I am running a Xubuntu 14.04 LTS guest. I am not using the virt-manager stuff at all for this VM.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.