Bug 1003287 - [abrt] qemu-system-x86-1.4.2-7.fc19: error_exit: Process /usr/bin/qemu-system-x86_64 was killed by signal 6 (SIGABRT)
[abrt] qemu-system-x86-1.4.2-7.fc19: error_exit: Process /usr/bin/qemu-system...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
abrt_hash:181f821c9eaf954dc4aee3ff672...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-01 12:56 EDT by John Lewis
Modified: 2013-09-02 12:38 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-02 12:38:50 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 (22.94 KB, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: cgroup (477 bytes, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: core_backtrace (15.71 KB, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: dso_list (9.37 KB, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: environ (99 bytes, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: limits (1.29 KB, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: maps (49.20 KB, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: open_fds (6.69 KB, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details
File: proc_pid_status (933 bytes, text/plain)
2013-09-01 12:56 EDT, John Lewis
no flags Details

  None (edit)
Description John Lewis 2013-09-01 12:56:02 EDT
Description of problem:
I had 3 KVM virtual machines running, and several tabs open in Chromium. The tab with G+ in suddenly began to run very slowly (and the mouse would only move sporadically). I switched to VT 2, ran top to see what was eating CPU then one of the qemu instances died. No idea what caused it. None of the VM's was doing anything strenuous, 1 VM had a Samba share mounted from the other. The Samba server was the Qemu process that died.

Version-Release number of selected component:
qemu-system-x86-1.4.2-7.fc19

Additional info:
reporter:       libreport-2.1.6
backtrace_rating: 4
cmdline:        /usr/bin/qemu-system-x86_64 -machine accel=kvm -name server1.example.com -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid cca5287f-8ad7-3147-81bf-2c03b91bdefc -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/server1.example.com.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 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 -drive file=/var/lib/libvirt/images/server1.example.com.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=2 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:7f:05:0f,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 -vga qxl -global qxl-vga.ram_size=67108864 -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: error_exit
executable:     /usr/bin/qemu-system-x86_64
kernel:         3.10.9-200.fc19.x86_64
runlevel:       N 5
uid:            107
var_log_messages: Sep  1 15:17:07 john-samsung-550-chromebook abrt[5112]: Saved core dump of pid 2367 (/usr/bin/qemu-system-x86_64) to /var/tmp/abrt/ccpp-2013-09-01-15:16:49-2367 (1451802624 bytes)

Truncated backtrace:
Thread no. 1 (5 frames)
 #2 error_exit at util/qemu-thread-posix.c:28
 #3 qemu_thread_create at util/qemu-thread-posix.c:295
 #4 do_spawn_thread at thread-pool.c:133
 #5 worker_thread at thread-pool.c:79
 #7 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Comment 1 John Lewis 2013-09-01 12:56:11 EDT
Created attachment 792627 [details]
File: backtrace
Comment 2 John Lewis 2013-09-01 12:56:16 EDT
Created attachment 792628 [details]
File: cgroup
Comment 3 John Lewis 2013-09-01 12:56:21 EDT
Created attachment 792629 [details]
File: core_backtrace
Comment 4 John Lewis 2013-09-01 12:56:27 EDT
Created attachment 792630 [details]
File: dso_list
Comment 5 John Lewis 2013-09-01 12:56:32 EDT
Created attachment 792631 [details]
File: environ
Comment 6 John Lewis 2013-09-01 12:56:37 EDT
Created attachment 792632 [details]
File: limits
Comment 7 John Lewis 2013-09-01 12:56:44 EDT
Created attachment 792633 [details]
File: maps
Comment 8 John Lewis 2013-09-01 12:56:49 EDT
Created attachment 792634 [details]
File: open_fds
Comment 9 John Lewis 2013-09-01 12:56:55 EDT
Created attachment 792635 [details]
File: proc_pid_status
Comment 10 Cole Robinson 2013-09-02 12:38:50 EDT
Thanks for the report. The crash came from pthread_create failing, something that really shouldn't happen and likely isn't a qemu bug. Given that you described general machine weirdness, I'm going to assume this is hardware or kernel related. Maybe see if you have any scary errors in dmesg you can try filing a kernel bug.

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