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
Created attachment 792627 [details] File: backtrace
Created attachment 792628 [details] File: cgroup
Created attachment 792629 [details] File: core_backtrace
Created attachment 792630 [details] File: dso_list
Created attachment 792631 [details] File: environ
Created attachment 792632 [details] File: limits
Created attachment 792633 [details] File: maps
Created attachment 792634 [details] File: open_fds
Created attachment 792635 [details] File: proc_pid_status
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.