Bug 1031564 - [abrt] qemu-system-x86-1.6.1-1.fc20: pixman_image_get_data: Process /usr/bin/qemu-system-x86_64 was killed by signal 11 (SIGSEGV)
[abrt] qemu-system-x86-1.6.1-1.fc20: pixman_image_get_data: Process /usr/bin/...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
22
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
https://retrace.fedoraproject.org/faf...
abrt_hash:03b6f531981f60627fabdd5ec8a...
: Reopened
: 1103107 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-18 05:10 EST by Amit Shah
Modified: 2015-05-31 15:23 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-05-31 15:23:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (23.80 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: cgroup (159 bytes, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: core_backtrace (10.96 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: dso_list (13.63 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: environ (3.29 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: exploitable (82 bytes, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: limits (1.29 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: maps (66.88 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: open_fds (1.11 KB, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: proc_pid_status (934 bytes, text/plain)
2013-11-18 05:11 EST, Amit Shah
no flags Details
File: var_log_messages (716 bytes, text/plain)
2013-11-18 05:12 EST, Amit Shah
no flags Details
grub.cfg of the frequently UCD 3.2 / Debian Sarge vm (4.85 KB, text/plain)
2014-02-11 08:29 EST, Christoph Wickert
no flags Details
virsh dumpxml debianwheezy (3.67 KB, application/xml)
2014-08-31 08:46 EDT, Jeremy Harris
no flags Details

  None (edit)
Description Amit Shah 2013-11-18 05:10:48 EST
Description of problem:
Start a VM with spice / qxl and got this crash.

Without qxl, this works fine.

Version-Release number of selected component:
qemu-system-x86-1.6.1-1.fc20

Additional info:
reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -m 1G -smp 2 -enable-kvm -cpu host,+x2apic -soundhw hda -no-hpet -net nic,model=virtio -net user -drive file=/guests/f16-flash.qcow2,if=none,cache=unsafe,id=dr0 -device virtio-blk-pci,drive=dr0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=auto_glz,streaming-video=filter -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -vga qxl -usb -snapshot
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.11.8-300.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 pixman_image_get_data at pixman-image.c:843
 #1 surface_data at /usr/src/debug/qemu-1.6.1/include/ui/console.h:235
 #2 vga_draw_graphic at /usr/src/debug/qemu-1.6.1/hw/display/vga.c:1789
 #3 vga_update_display at /usr/src/debug/qemu-1.6.1/hw/display/vga.c:1918
 #4 qemu_spice_display_refresh at ui/spice-display.c:417
 #5 dpy_refresh at ui/console.c:1436
 #6 gui_update at ui/console.c:192
 #7 qemu_run_timers at qemu-timer.c:394
 #9 qemu_run_all_timers at qemu-timer.c:453
 #10 main_loop_wait at main-loop.c:471
Comment 1 Amit Shah 2013-11-18 05:11:03 EST
Created attachment 825457 [details]
File: backtrace
Comment 2 Amit Shah 2013-11-18 05:11:08 EST
Created attachment 825458 [details]
File: cgroup
Comment 3 Amit Shah 2013-11-18 05:11:14 EST
Created attachment 825459 [details]
File: core_backtrace
Comment 4 Amit Shah 2013-11-18 05:11:21 EST
Created attachment 825460 [details]
File: dso_list
Comment 5 Amit Shah 2013-11-18 05:11:26 EST
Created attachment 825461 [details]
File: environ
Comment 6 Amit Shah 2013-11-18 05:11:33 EST
Created attachment 825462 [details]
File: exploitable
Comment 7 Amit Shah 2013-11-18 05:11:39 EST
Created attachment 825463 [details]
File: limits
Comment 8 Amit Shah 2013-11-18 05:11:45 EST
Created attachment 825464 [details]
File: maps
Comment 9 Amit Shah 2013-11-18 05:11:52 EST
Created attachment 825465 [details]
File: open_fds
Comment 10 Amit Shah 2013-11-18 05:11:59 EST
Created attachment 825466 [details]
File: proc_pid_status
Comment 11 Amit Shah 2013-11-18 05:12:05 EST
Created attachment 825467 [details]
File: var_log_messages
Comment 12 Amit Shah 2013-11-18 05:56:39 EST
Not reproducible upstream
Comment 13 Cole Robinson 2013-11-19 14:41:58 EST
(In reply to Amit Shah from comment #12)
> Not reproducible upstream

So is this regularly reproducible for you? What's the guest OS?

> 
> Truncated backtrace:
> Thread no. 1 (10 frames)
>  #0 pixman_image_get_data at pixman-image.c:843
>  #1 surface_data at /usr/src/debug/qemu-1.6.1/include/ui/console.h:235
>  #2 vga_draw_graphic at /usr/src/debug/qemu-1.6.1/hw/display/vga.c:1789
>  #3 vga_update_display at /usr/src/debug/qemu-1.6.1/hw/display/vga.c:1918
>  #4 qemu_spice_display_refresh at ui/spice-display.c:417
>  #5 dpy_refresh at ui/console.c:1436
>  #6 gui_update at ui/console.c:192
>  #7 qemu_run_timers at qemu-timer.c:394
>  #9 qemu_run_all_timers at qemu-timer.c:453
>  #10 main_loop_wait at main-loop.c:471

CCing spice folks
Comment 14 Amit Shah 2013-11-20 01:02:39 EST
(In reply to Cole Robinson from comment #13)
> (In reply to Amit Shah from comment #12)
> > Not reproducible upstream
> 
> So is this regularly reproducible for you? What's the guest OS?

Yes, easily.  Guest is F19.
Comment 15 Amit Shah 2013-11-20 01:03:50 EST
(In reply to Amit Shah from comment #14)
> (In reply to Cole Robinson from comment #13)
> > (In reply to Amit Shah from comment #12)
> > > Not reproducible upstream
> > 
> > So is this regularly reproducible for you? What's the guest OS?
> 
> Yes, easily.  Guest is F19.

This happens right after the grub timeout, so maybe when plymouth kicks in.
Comment 16 Cole Robinson 2013-11-20 15:04:04 EST
Hmm, I plugged my existing f19 image into your command line and still couldn't reproduce.

Someone from the spice side want to chime in?
Comment 17 reposer 2014-01-04 10:00:05 EST
Another user experienced a similar problem:

I used virt-manager 0.10.0
I added Opensuse 12.3 and it went until automatic configuration

reporter:       libreport-2.1.10
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name opensuse12 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 47eeb5ec-170d-466b-adbe-5ecb89d298a1 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/opensuse12.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/opensuse12.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:80:13:db,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -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=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.12.6-300.fc20.i686+PAE
package:        qemu-system-x86-1.6.1-3.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 18 Christoph Wickert 2014-01-14 09:07:53 EST
Pretty common for me on Fedora 20 when I start a machine. I've never seen this on F19. I also haven't noticed any negative side effects, just ABRT telling me something crashed.

rpm -qa *qemu* | sort
ipxe-roms-qemu-20130517-3.gitc4bce43.fc20.noarch
libvirt-daemon-driver-qemu-1.1.3.2-1.fc20.x86_64
qemu-common-1.6.1-3.fc20.x86_64
qemu-guest-agent-1.6.1-3.fc20.x86_64
qemu-img-1.6.1-3.fc20.x86_64
qemu-kvm-1.6.1-3.fc20.x86_64
qemu-system-x86-1.6.1-3.fc20.x86_64

Hope this helps.
Comment 19 Christoph Wickert 2014-01-14 09:10:51 EST
(In reply to Christoph Wickert from comment #18)
> I also haven't noticed any negative side effects, just ABRT
> telling me something crashed.

Sorry, actually the VM crashed.
Comment 20 Gerd Hoffmann 2014-01-17 09:16:41 EST
(In reply to Amit Shah from comment #15)
> (In reply to Amit Shah from comment #14)
> > (In reply to Cole Robinson from comment #13)
> > > (In reply to Amit Shah from comment #12)
> > > > Not reproducible upstream
> > > 
> > > So is this regularly reproducible for you? What's the guest OS?
> > 
> > Yes, easily.  Guest is F19.
> 
> This happens right after the grub timeout, so maybe when plymouth kicks in.

How does your grub config look like?
Does it also happen when booting a F19 live iso?
Comment 21 Amit Shah 2014-01-17 14:21:55 EST
Can't reproduce anymore.  Using qemu-kvm-1.6.1-3.fc20.x86_64.  Can't remember if I updated the guest in the meantime -- but since it works with latest bits, closing.
Comment 22 Václav Mocek 2014-02-01 09:56:51 EST
Unfortunately, it still randomly happens.
Comment 23 Christoph Wickert 2014-02-11 05:51:47 EST
Reopening, I'm now on x86-1.6.1-3.fc20.x86_64. and still see this quite often with some VMs, mostly Debian systems. Please let me know what configuration files you want me to provide, e.g. only grub.cfg or something else?
Comment 24 Cole Robinson 2014-02-11 08:06:39 EST
(In reply to Christoph Wickert from comment #23)
> Reopening, I'm now on x86-1.6.1-3.fc20.x86_64. and still see this quite
> often with some VMs, mostly Debian systems. Please let me know what
> configuration files you want me to provide, e.g. only grub.cfg or something
> else?

Is the symptom the same, crashing soon after grub? If so, please provide the grub.cfg as gerd suggests, and the qemu command line (/var/log/libvirt/qemu/$vmname.log if using libvirt)
Comment 25 Christoph Wickert 2014-02-11 08:29:49 EST
Created attachment 861783 [details]
grub.cfg of the frequently UCD 3.2 / Debian Sarge vm

Here you are the grub.cfg file and a log excerpt. As you can see on the timestamps, the machine crashes 4,2 seconds after start, the grub timeout is 5 seconds.

q2014-02-11 13:17:51.730+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name ucs32test-kolab31 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid f3a0ffb9-0705-49ad-8624-069295a05c65 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ucs32test-kolab31.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=/home/libvirt/images/ucs32test-kolab31.img,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=1 -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 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:9a:eb:4a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -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
char device redirected to /dev/pts/7 (label charserial0)
2014-02-11 13:17:55.904+0000: shutting down
Comment 26 Cole Robinson 2014-02-11 08:55:53 EST
Thanks Christophe. Gerd, thoughts?
Comment 27 Christoph Wickert 2014-02-18 08:30:00 EST
This is pretty annoying, the crash occurs in at least 1 of two launches of this (and similar) VMs.
Comment 28 Alon Levy 2014-02-24 08:42:48 EST
(In reply to Christoph Wickert from comment #27)
> This is pretty annoying, the crash occurs in at least 1 of two launches of
> this (and similar) VMs.

Hi Christoph,

 I tried reproducing with a debian 7.4.0 install on which I overwrote the installed grub.cfg with attachment 861783 [details], and with the command line above, only difference is removing the tap network and the monitor char device. Of course the kernel didn't boot but I understood the crash happened before the timeout, so before kernel loading, is that correct? I failed to reproduce this way. Can you provide more details on your setup? qemu & spice-server versions will help, thanks,

Alon
Comment 29 Christoph Wickert 2014-02-24 11:04:09 EST
(In reply to Alon Levy from comment #28)
>
>  I tried reproducing with a debian 7.4.0 install on which I overwrote the
> installed grub.cfg with attachment 861783 [details], and with the command
> line above, only difference is removing the tap network and the monitor char
> device. Of course the kernel didn't boot but I understood the crash happened
> before the timeout, so before kernel loading, is that correct?

I cannot really test. For some reason, the crash only seems to happen, when I do not have virt-viewer connected to the machine. If I start the machine from virsh or with a right-click from virt-viewer, it crashes quite in more than 50% of the cases, but if I open the machine so that virt-viewer is connected, it does not crash in 10 times. Very strange.

> I failed to
> reproduce this way. Can you provide more details on your setup?

Sure.

rpm -qa *libvirt* *kernel* *kvm* *spice* *qemu* | sort
abrt-addon-kerneloops-2.1.12-2.fc20.x86_64
ipxe-roms-qemu-20130517-3.gitc4bce43.fc20.noarch
kernel-3.12.10-300.fc20.x86_64
kernel-3.12.8-300.fc20.x86_64
kernel-3.13.3-201.fc20.x86_64
kernel-devel-3.12.10-300.fc20.x86_64
kernel-devel-3.12.8-300.fc20.x86_64
kernel-devel-3.13.3-201.fc20.x86_64
kernel-headers-3.13.3-201.fc20.x86_64
kernel-modules-extra-3.12.10-300.fc20.x86_64
kernel-modules-extra-3.12.8-300.fc20.x86_64
kernel-modules-extra-3.13.3-201.fc20.x86_64
libreport-plugin-kerneloops-2.1.12-2.fc20.x86_64
libvirt-1.1.3.3-5.fc20.x86_64
libvirt-client-1.1.3.3-5.fc20.x86_64
libvirt-daemon-1.1.3.3-5.fc20.x86_64
libvirt-daemon-config-network-1.1.3.3-5.fc20.x86_64
libvirt-daemon-config-nwfilter-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-interface-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-libxl-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-lxc-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-network-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-nodedev-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-nwfilter-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-qemu-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-secret-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-storage-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-uml-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-vbox-1.1.3.3-5.fc20.x86_64
libvirt-daemon-driver-xen-1.1.3.3-5.fc20.x86_64
libvirt-glib-0.1.7-2.fc20.x86_64
libvirt-python-1.1.3.3-5.fc20.x86_64
qemu-common-1.6.1-3.fc20.x86_64
qemu-guest-agent-1.6.1-3.fc20.x86_64
qemu-img-1.6.1-3.fc20.x86_64
qemu-kvm-1.6.1-3.fc20.x86_64
qemu-system-x86-1.6.1-3.fc20.x86_64
spice-glib-0.22-1.fc20.x86_64
spice-gtk-0.22-1.fc20.x86_64
spice-gtk3-0.22-1.fc20.x86_64
spice-gtk-python-0.22-1.fc20.x86_64
spice-server-0.12.4-3.fc20.x86_64
spice-vdagent-0.15.0-1.fc20.x86_64
Comment 30 Christoph Wickert 2014-03-05 10:16:40 EST
Is there anything I can do to help you debugging this?
Comment 31 Christophe Fergeau 2014-03-05 13:09:57 EST
Short of managing to reliably reproduce on a machine we have access to, what could be helpful is
- a core file
- in particular, a core file generated with this scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=6601779 which is f20 qemu compiled without optimization would be useful. If you can't get a core file, a backtrace generated with these packages installed would be nice
Comment 32 Michael Catanzaro 2014-03-21 19:20:49 EDT
I have a Debian 7 VM in GNOME Boxes. I selected the VM, clicked on Properties, then clicked on Devices. This crash occurred and Boxes immediately returned to the start screen where I can select from my VMs.

Not reproducible.
Comment 33 Christophe Fergeau 2014-05-30 11:47:31 EDT
*** Bug 1103107 has been marked as a duplicate of this bug. ***
Comment 34 Christophe Fergeau 2014-05-30 11:57:20 EDT
Christoph, are you still hitting this very regularly?
Comment 35 Christoph Wickert 2014-06-02 14:04:30 EDT
(In reply to Christophe Fergeau from comment #34)
> Christoph, are you still hitting this very regularly?

Yes, but only with certain VMs and I cannot get a proper core file. ABRT does not like the not-optimized packages (backtrace too big). Ideas?
Comment 36 Oron Peled 2014-06-02 17:41:55 EDT
When I saw comment #34 I immediately re-tested it:
* It does happen consistently.
* When I run a single VM at the same time, the host is still responsive during the qemu deadlock, so I can do a "virsh destroy ..."
* When I run two VM's at the same time, the deadlock affect very badly on the host, so I cannot even interact with virsh (so I had to hard-reset the host).
* The host is 4-core relatively old PC with only 4Gb memory. Each VM get only 1-vcpu and 1Gb ram.

However, this was my last i686 host and its time has come:
* Yesterday I cross-graded it to x86_64 (I know, totally unsupported hack with lots of manual work, but still).
* Since than, my VM's runs really nice together (ran 3 at a time without any problem).
* So from now on, I have no way to help with this bug -- sorry.
Comment 37 Christophe Fergeau 2014-06-03 04:42:56 EDT
(In reply to Christoph Wickert from comment #35)
> (In reply to Christophe Fergeau from comment #34)
> > Christoph, are you still hitting this very regularly?
> 
> Yes, but only with certain VMs and I cannot get a proper core file. ABRT
> does not like the not-optimized packages (backtrace too big). Ideas?

You could attach gdb to the qemu process before it crashes: ps aux |grep qemu- and then gdb --pid xxxx with 'xxxx' being the PID of the relevant qemu. gdb --pid $(pidof qemu-kvm) should work if that's the only VM running. You need to do that as root. However as the VM seems to crash shortly after startup, this might not be feasible. You can also try to run the VM with virsh from the command line: virsh start --paused, attach gdb, and then virsh resume (I think).
Comment 38 Christophe Fergeau 2014-06-03 04:44:00 EDT
Can you also attach the libvirt XML description of the crashing VM? virsh dumpxml foo (virsh -c qemu:///system list --all or virsh -c qemu:///session list --all to get the valid VM names)
Comment 39 Jeremy Harris 2014-06-15 11:23:11 EDT
Another user experienced a similar problem:

Starting a set of VMs from script (which does "virsh start mch-name" a few times).
Possibly one of the VMs was already running.

reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name debianwheezy -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 1b438569-d82c-4f34-8a18-0df150e5efe2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/debianwheezy.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/hd/images/deb-7.5,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:ba:0e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5904,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.14.6-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-6.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 40 Victor Stinner 2014-06-16 10:54:09 EDT
Another user experienced a similar problem:

I just try to boot my Debian Sid VM.

reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name debianwheezy -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2c1d8ea0-cd3f-4d6b-a9b4-cfc44f9f7323 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/debianwheezy.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/debianwheezy.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:be:ad:4f,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -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=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.14.4-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-5.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 41 Jeremy Harris 2014-08-06 07:03:41 EDT
Another user experienced a similar problem:

Starting a Suse 13.1 VM using virsh.

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name suse13_1_i586 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 4cdb435c-aa86-4b74-bd72-a84fe02ec3b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/suse13_1_i586.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/hd/images/suse13_1_i585.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c8:06:52,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5904,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.15.7-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-7.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 42 Jeremy Harris 2014-08-11 09:01:08 EDT
Another user experienced a similar problem:

Unsure.  Might have been at VM startup (virsh start foo, from a shellscript run under sudo), might have been after.

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name debianwheezy -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 1b438569-d82c-4f34-8a18-0df150e5efe2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/debianwheezy.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/hd/images/deb-7.5,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:ba:0e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5903,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.15.8-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-7.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 43 Jeremy Harris 2014-08-31 08:43:12 EDT
Update on the above: the common crasher VMs are Debian (Wheezy) and Suse (13.1 i586).  Non-crashers being started by the same script are f19, rhel7, freebsd 9.
Comment 44 Jeremy Harris 2014-08-31 08:46:30 EDT
Created attachment 933133 [details]
virsh dumpxml debianwheezy
Comment 45 Jeremy Harris 2014-09-16 10:51:00 EDT
Another user experienced a similar problem:

Starting up a bunch of VMs from script, using "virsh start <name>"

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name suse13_1_i586 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 4cdb435c-aa86-4b74-bd72-a84fe02ec3b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/suse13_1_i586.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/hd/images/suse13_1_i585.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c8:06:52,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5904,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.16.2-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-8.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 46 Jeremy Harris 2014-10-22 10:05:37 EDT
Another user experienced a similar problem:

Starting a VM from the Virtual Machine Manager list-of-VMs window; right-click in VM name for context-menu, left-click on Run.  VM was listed as "Shutoff" state and there was no console window open for it.

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name debianwheezy -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 1b438569-d82c-4f34-8a18-0df150e5efe2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/debianwheezy.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/hd/images/deb-7.5,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:ba:0e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5905,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.16.6-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-9.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 47 Jeremy Harris 2014-11-27 04:12:35 EST
Another user experienced a similar problem:

Starting VMs from script

reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name suse13_1_i586 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 4cdb435c-aa86-4b74-bd72-a84fe02ec3b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/suse13_1_i586.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/hd/images/suse13_1_i585.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c8:06:52,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5904,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: pixman_image_get_data
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.17.3-200.fc20.x86_64
package:        qemu-system-x86-1.6.2-10.fc20
reason:         qemu-system-x86_64 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            107
Comment 48 Fedora End Of Life 2015-05-29 05:47:32 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 '20'.

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 20 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.
Comment 49 Cole Robinson 2015-05-31 15:23:07 EDT
This has over 200 faf hits, but they are all from F20 vintage. So I'm assuming this is fixed in F21+.

Just closing as F20 is EOL soon and this is unlikely to be fixed in an update at this point.

Note You need to log in before you can comment on or make changes to this bug.