Bug 1031564

Created attachment 825457 [details]
File: backtrace

Created attachment 825458 [details]
File: cgroup

Created attachment 825459 [details]
File: core_backtrace

Created attachment 825460 [details]
File: dso_list

Created attachment 825461 [details]
File: environ

Created attachment 825462 [details]
File: exploitable

Created attachment 825463 [details]
File: limits

Created attachment 825464 [details]
File: maps

Created attachment 825465 [details]
File: open_fds

Created attachment 825466 [details]
File: proc_pid_status

Created attachment 825467 [details]
File: var_log_messages

Not reproducible upstream

(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

(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.

(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.

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?

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

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.

(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.

(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?

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.

Unfortunately, it still randomly happens.

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?

(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)

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

Thanks Christophe. Gerd, thoughts?

This is pretty annoying, the crash occurs in at least 1 of two launches of this (and similar) VMs.

(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

(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

Is there anything I can do to help you debugging this?

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

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.

*** Bug 1103107 has been marked as a duplicate of this bug. ***

Christoph, are you still hitting this very regularly?

(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?

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.

(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).

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)

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

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

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

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

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.

Created attachment 933133 [details]
virsh dumpxml debianwheezy

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

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

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

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.

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.