Created attachment 1018904 [details]
File: backtrace

Created attachment 1018905 [details]
File: cgroup

Created attachment 1018906 [details]
File: core_backtrace

Created attachment 1018907 [details]
File: dso_list

Created attachment 1018908 [details]
File: environ

Created attachment 1018909 [details]
File: limits

Created attachment 1018910 [details]
File: maps

Created attachment 1018911 [details]
File: mountinfo

Created attachment 1018912 [details]
File: namespaces

Created attachment 1018913 [details]
File: open_fds

Created attachment 1018914 [details]
File: proc_pid_status

Another user experienced a similar problem:

Tried to add an ISO image from a remote SMB server in Boxes.

reporter:       libreport-2.5.1
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name fedora21 -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid 4f17c4f6-ff62-4cf9-8319-a2e104e3b78e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/hadess/.config/libvirt/qemu/lib/fedora21.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-reboot -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/home/hadess/.local/share/gnome-boxes/images/fedora21,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive file=/run/user/1000/gvfs/smb-share:server=diskstation.local,,share=bastien/ISOs/Fedora-Live-Workstation-x86_64-21-5.iso,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=21,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:24:b3,bus=pci.0,addr=0x3 -chardev spicevmc,id=charsmartcard0,name=smartcard -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 -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 -device usb-mouse,id=input1 -device usb-kbd,id=input2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -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 -msg timestamp=on
crash_function: error_propagate
executable:     /usr/bin/qemu-system-x86_64
global_pid:     18509
kernel:         4.0.0-0.rc5.git4.1.fc22.x86_64
package:        qemu-system-x86-2.3.0-0.3.rc2.fc22
reason:         qemu-system-x86_64 killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            1000

Another user experienced a similar problem:

Tried to create a new VM via Gnome Boxes app.

Step 1) Click on New
Step 2) Click on Enter URL and insert http://mirror.acsnet.com/centos/6.6/isos/x86_64/CentOS-6.6-x86_64-bin-DVD1.iso into the field.

Boxes will download the ISO image and attempt to start qemu. At this point qemu crashes and core dumps.

reporter:       libreport-2.5.1
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name boxes-unknown -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu Westmere -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid 6c3e7512-84df-4cdd-97a7-831e19313d42 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rgraham/.config/libvirt/qemu/lib/boxes-unknown.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-reboot -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/home/rgraham/.local/share/gnome-boxes/images/boxes-unknown,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive file=/home/rgraham/Downloads/CentOS-6.6-x86_64-bin-DVD1.iso,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=22,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:04:e7:54,bus=pci.0,addr=0x3 -chardev spicevmc,id=charsmartcard0,name=smartcard -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 -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 -device usb-mouse,id=input1 -device usb-kbd,id=input2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -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=0x7 -msg timestamp=on
crash_function: error_propagate
executable:     /usr/bin/qemu-system-x86_64
global_pid:     28859
kernel:         4.0.4-301.fc22.x86_64
package:        qemu-system-x86-2.3.0-4.fc22
reason:         qemu-system-x86_64 killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            1000

Anyone that hit this, can you post /var/log/libvirt/qemu/$vmname.log ?
If using gnome-boxes, that will be ~/.cache/libvirt/qemu/log/$vmname.log

I updated to the newest gnome-boxes package on 5/30/15 and have not experienced qemu crashing since.

Previous package release:
gnome-boxes-3.16.2-1.fc22.x86_64

Current package release:
gnome-boxes-3.16.2-2.fc22.x86_64

Created attachment 1035975 [details]
boxes-unknown.log

Hmm, that log file doesn't seem to contain bits about the VM when it crashed. Annoyingly it's filled with tons of

((null):7924): Spice-Warning **: red_channel.c:546:red_channel_client_send_ping: getsockopt failed, Operation not supported

Probably a side effect of running as non-root. But it doesn't seem to the be the root issue. So if anyone else hits this crash again, please attach the qemu log file as well

I think my reading of the original backtrace makes me think it's an out-of-ram failure.

 #2 error_propagate at util/error.c:173
 #3 qemu_ram_alloc_internal at /usr/src/debug/qemu-2.3.0-rc3/exec.c:1544
that's checking for errors just after 'ram_block_add'

and looking inside ram_block_add the only place the error gets set is by phys_mem_alloc failing.

 #4 qemu_ram_alloc at /usr/src/debug/qemu-2.3.0-rc3/exec.c:1558
 #5 memory_region_init_ram at /usr/src/debug/qemu-2.3.0-rc3/memory.c:1138
 #6 allocate_system_memory_nonnuma at /usr/src/debug/qemu-2.3.0-rc3/numa.c:341

In here we have:
        memory_region_init_ram(mr, owner, name, ram_size, &error_abort);
and commit 49946538 started passing error_abort to that.


 #7 memory_region_allocate_system_memory at /usr/src/debug/qemu-2.3.0-rc3/numa.c:354
 #8 pc_memory_init at /usr/src/debug/qemu-2.3.0-rc3/hw/i386/pc.c:1248
 #9 pc_init1 at /usr/src/debug/qemu-2.3.0-rc3/hw/i386/pc_piix.c:183

Dave

I am probably hitting this problem. If you need some information that may helps you, please let me know.

I hit the bug simply by running 

[maci@mwysocki ~]$ qemu-system-or32 
qemu: fatal: Trying to execute code outside RAM or ROM at 0x08000000

PC=08000000
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00000000
R16=00000000 R17=00000000 R18=00000000 R19=00000000
R20=00000000 R21=00000000 R22=00000000 R23=00000000
R24=00000000 R25=00000000 R26=00000000 R27=00000000
R28=00000000 R29=00000000 R30=00000000 R31=00000000
Aborted (core dumped)
[maci@mwysocki ~]$ 


all I did was scroll up and down a bit in the qemu window

(In reply to Marcel Wysocki from comment #20)
> I hit the bug simply by running 
> 
> [maci@mwysocki ~]$ qemu-system-or32 
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x08000000
> 
> PC=08000000
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=00000000 R14=00000000 R15=00000000
> R16=00000000 R17=00000000 R18=00000000 R19=00000000
> R20=00000000 R21=00000000 R22=00000000 R23=00000000
> R24=00000000 R25=00000000 R26=00000000 R27=00000000
> R28=00000000 R29=00000000 R30=00000000 R31=00000000
> Aborted (core dumped)
> [maci@mwysocki ~]$ 
> 
> 
> all I did was scroll up and down a bit in the qemu window

Marcel: That's a different problem. This bug is only for a SIGABRT which includes memory_region_allocate_system_memory in the backtrace.

Yeah this abort() is just when too much ram has been requested. qemu previously did exit(1) here instead but that regressed. Markus has patches on qemu-devel to fix it but they touch a lot of files:

https://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg03198.html

Those patches are in rawhide, so it should be 'fixed' there. But I think we just have to live with this problem for f23 and earlier.

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

Similar problem has been detected:

I tried to install Windows 7 x64 via gnome-boxes

reporter:       libreport-2.6.4
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name win7-profess -S -machine pc-i440fx-2.4,accel=kvm,usb=off -cpu Haswell-noTSX -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -uuid 473e9d4e-b9fd-4b67-851b-9d3d339bcf89 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/drindt/.config/libvirt/qemu/lib/win7-profess.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/home/drindt/.local/share/gnome-boxes/images/win7-profess,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive file=/home/drindt/Downloads/de_windows_7_professional_with_sp1_x64_dvd_u_676919.iso,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=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:47:82:e4,bus=pci.0,addr=0x3 -chardev spicevmc,id=charsmartcard0,name=smartcard -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 -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 -device usb-mouse,id=input1 -device usb-kbd,id=input2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,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=0x7 -msg timestamp=on
crash_function: error_propagate
executable:     /usr/bin/qemu-system-x86_64
global_pid:     787
kernel:         4.4.4-301.fc23.x86_64
package:        qemu-system-x86-2.4.1-7.fc23
reason:         qemu-system-x86_64 killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            1000

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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

confirm fixed in f25 (not sure about 24)

f24 has the fixes as well, so closing against f24