Version-Release number of selected component: qemu-system-x86-1.2.2-6.fc18 Additional info: backtrace_rating: 4 cmdline: /usr/bin/qemu-kvm -name Lubuntu32 -S -M pc-1.2 -cpu SandyBridge,+osxsave,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 2048 -smp 4,sockets=4,cores=1,threads=1 -uuid 4bd3b710-8f57-325e-e07b-6e89f9a85759 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Lubuntu32.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/data/znmeb/VirtManager/Lubuntu32.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d3:d9:14,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 crash_function: check_solid_tile32 executable: /usr/bin/qemu-kvm kernel: 3.8.1-201.fc18.x86_64 uid: 107 Truncated backtrace: Thread no. 1 (6 frames) #0 check_solid_tile32 at ui/vnc-enc-tight.c:708 #1 check_solid_tile at ui/vnc-enc-tight.c:719 #2 find_large_solid_color_rect at ui/vnc-enc-tight.c:1655 #3 tight_send_framebuffer_update at ui/vnc-enc-tight.c:1742 #4 vnc_worker_thread_loop at ui/vnc-jobs.c:258 #5 vnc_worker_thread at ui/vnc-jobs.c:318
Created attachment 707690 [details] File: backtrace
Created attachment 707691 [details] File: build_ids
Created attachment 707692 [details] File: cgroup
Created attachment 707693 [details] File: core_backtrace
Created attachment 707694 [details] File: dso_list
Created attachment 707695 [details] File: environ
Created attachment 707696 [details] File: limits
Created attachment 707697 [details] File: maps
Created attachment 707698 [details] File: open_fds
Created attachment 707699 [details] File: proc_pid_status
Created attachment 707700 [details] File: var_log_messages
Can you explain what you were doing roughly?
I can reliably reproduce here by booting an F18 guest with qxl+vnc. Crashes when transitioning to GDM. Can't reproduce with upstream, or 1.4 or 1.3, or stock 1.2.2... After poking at it for far too long, I think what's happening is - guest enters VGA mode - qxl_enter_vga_mode calls vnc_dpy_resize - vnc_dpy_resize reallocates DisplaySurface->data, exits - a vnc thread gets kicked off - qxl_render_update_area_bh is kicked off from main thread, calls qemu_resize_displaysurface. this changes DisplaySurface->linesize to a larger value than was used to allocate DisplaySurface->data - running vnc thread calculates fbptr using the new linesize, accesses unallocated memory, segfault If there's a simple fix it didn't jump out at me. We can 'fix' it by reverting this patch: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0518-qxl-call-dpy_gfx_resize-when-entering-vga-mode.patch?h=f18 Which is step #2 above, but that patch is supposedly need to prevent another crash :( Any suggestions?
Created attachment 711786 [details] Fix Shot in the dark: Does the attached patch fix it?
I'm running Windows Vista in a VM. If I open and close the machine display window a few times, it crashes when using both spice and VNC modes. backtrace_rating: 4 Package: qemu-system-x86-1.2.2-6.fc18 OS Release: Fedora release 18 (Spherical Cow)
(In reply to comment #14) > Created attachment 711786 [details] > Fix > > Shot in the dark: Does the attached patch fix it? That makes the crash go away for me, thanks Gerd. Is it safe to push to F18?
Yes. (commit c099e7aa0295678859d58e9e60b7619f6ae3bac8 meanwhile btw).
qemu-1.2.2-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-8.fc18
Package qemu-1.2.2-8.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qemu-1.2.2-8.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4711/qemu-1.2.2-8.fc18 then log in and leave karma (feedback).
qemu-1.2.2-9.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-9.fc18
The problem seems to be still there for me with qemu-1.2.2-9.fc18.x86_64. My qemu command line is: ionice -c 3 qemu-kvm -enable-kvm -m 2048M -smp 1 -drive file=./Fedora-19-Alpha-TC4-x86_64-netinst-test.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-19-Alpha-TC4-x86_64-netinst-test.iso.qcow2-output.log -name Fedora-19-Alpha-TC4-x86_64-netinst-test.iso.qcow2 -cdrom /local/mfabian/iso/Fedora-19-Alpha-TC4/Fedora-19-Alpha-TC4-x86_64-netinst.iso -boot c -vga qxl -display vnc=:5 -net nic -net user,hostname=Fedora-19-Alpha-TC4-x86_64-netinst-test.iso.qcow2,hostfwd=tcp::5562-:22 -monitor stdio -usb executable: /usr/bin/qemu-kvm kernel: kernel-3.8.3-203.fc18.x86_64 Backtrace: (gdb) bt bt #0 0x00007fece99e3872 in check_solid_tile32 (vs=<optimized out>, vs=<optimized out>, samecolor=true, color=0x7fec4b1e8450, h=16, w=16, y=<optimized out>, x=-375437757) at ui/vnc-enc-tight.c:708 #1 check_solid_tile (vs=vs@entry=0x7fec4b1e84b0, x=x@entry=0, y=y@entry=272, w=w@entry=16, h=h@entry=16, color=color@entry=0x7fec4b1e8450, samecolor=samecolor@entry=true) at ui/vnc-enc-tight.c:719 #2 0x00007fece99e682e in find_best_solid_area (h_ptr=<synthetic pointer>, w_ptr=<synthetic pointer>, color=5723904, h=400, w=720, y=0, x=0, vs= 0x7fec4b1e84b0) at ui/vnc-enc-tight.c:741 #3 find_large_solid_color_rect (max_rows=91, h=400, w=720, y=0, x=0, vs= 0x7fec4b1e84b0) at ui/vnc-enc-tight.c:1661 #4 tight_send_framebuffer_update (vs=0x7fec4b1e84b0, x=0, y=0, w=720, h=400) at ui/vnc-enc-tight.c:1742 #5 0x00007fece99f02e0 in vnc_worker_thread_loop (queue=queue@entry= 0x7feceab56ff0) at ui/vnc-jobs.c:258 #6 0x00007fece99f04b0 in vnc_worker_thread (arg=0x7feceab56ff0) at ui/vnc-jobs.c:318 #7 0x00007fece7846d15 in start_thread (arg=0x7fec4b1fb700) at pthread_create.c:308 #8 0x00007fece346748d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 (gdb)
With qemu-1.4.0-11.fc18.x86_64 from https://fedoraproject.org/wiki/Virtualization_Preview_Repository the crash does not seem to happen anymore, but I get pixel garbage then, see bug#948717.
qemu-1.2.2-10.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-10.fc18
qemu-1.2.2-10.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I still get a somewhat similar-looking backtrace with qemu-kvm-1.2.2-10.fc18.x86_64: Core was generated by `/usr/bin/qemu-kvm -name Fedora-19-x86_64 -S -M pc-1.2 -enable-kvm -m 2048 -smp'. Program terminated with signal 11, Segmentation fault. #0 0x00007f423d4af892 in check_solid_tile32 (vs=<optimized out>, vs=<optimized out>, samecolor=false, color=0x7f419eddd38c, h=16, w=16, y=<optimized out>, x=-1878623600) at ui/vnc-enc-tight.c:708 708 DEFINE_CHECK_SOLID_FUNCTION(32) (gdb) bt #0 0x00007f423d4af892 in check_solid_tile32 (vs=<optimized out>, vs=<optimized out>, samecolor=false, color= 0x7f419eddd38c, h=16, w=16, y=<optimized out>, x=-1878623600) at ui/vnc-enc-tight.c:708 #1 check_solid_tile (vs=vs@entry=0x7f419eddd4b0, x=x@entry=0, y=y@entry=71, w=w@entry=16, h=h@entry=16, color=color@entry=0x7f419eddd38c, samecolor=samecolor@entry=false) at ui/vnc-enc-tight.c:719 #2 0x00007f423d4b27d8 in find_large_solid_color_rect (max_rows=91, h=329, w=720, y=71, x=0, vs=0x7f419eddd4b0) at ui/vnc-enc-tight.c:1655 #3 tight_send_framebuffer_update (vs=vs@entry=0x7f419eddd4b0, x=x@entry=0, y=y@entry=71, w=w@entry=720, h=h@entry= 329) at ui/vnc-enc-tight.c:1742 #4 0x00007f423d4b2c58 in find_large_solid_color_rect (max_rows=91, h=400, w=720, y=0, x=0, vs=0x7f419eddd4b0) at ui/vnc-enc-tight.c:1700 #5 tight_send_framebuffer_update (vs=0x7f419eddd4b0, x=0, y=0, w=720, h=400) at ui/vnc-enc-tight.c:1742 #6 0x00007f423d4bc300 in vnc_worker_thread_loop (queue=queue@entry=0x7f423f1766f0) at ui/vnc-jobs.c:258 #7 0x00007f423d4bc4d0 in vnc_worker_thread (arg=0x7f423f1766f0) at ui/vnc-jobs.c:318 #8 0x00007f423b312d15 in start_thread (arg=0x7f419edf0700) at pthread_create.c:308 #9 0x00007f4236f3348d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114
Hmm. I think the fundamental issue here is the displaysurface interface, where the renderer (vnc/sdl/...) is notified about displaysurface changes after the fact. Which probably trips up vnc because it accesses the displaysurface from threads, which is obviously racy. So I guess c099e7aa0295678859d58e9e60b7619f6ae3bac8 just made the race window smaller, so it worked better with a bit of luck. In git master (and upcoming qemu 1.5) the displaysurface interface is fixed (first notify renderers, then release the old stuff), so the race is gone there. On 1.4 we have at least reference-counted displaysurfaces, so it should be fixable in when it reproduces there. Seems it doesn't though (comment #22). I think on qemu 1.2 the only reasonable option is to turn off the threaded vnc server.