abrt version: 1.1.8 architecture: x86_64 Attached file: backtrace cmdline: /usr/libexec/qemu-kvm -hda rawhide.x86_64.img -net nic,macaddr=DE:AD:BE:EF:92:19 -net tap -m 1024 comment: happens randomly in less then 2 seconds after start, it crashed 3 times so far (out of 20 runs) component: qemu-kvm crash_function: qemu_memalign executable: /usr/libexec/qemu-kvm kernel: 2.6.32-43.el6.x86_64 package: qemu-kvm-2:0.12.1.2-2.90.el6 rating: 4 reason: Process /usr/libexec/qemu-kvm was killed by signal 6 (SIGABRT) release: Red Hat Enterprise Linux Client release 6.0 Beta (Santiago) How to reproduce: see the command line time: 1278576323 uid: 0
Created attachment 430280 [details] File: backtrace
Note that you're not running it with the right parameters. Nevertheless, I don't see a reason for the failure. What happens when you use libvirt/virt-manager?
(In reply to comment #3) > Note that you're not running it with the right parameters. what is wrong with them? I'm using them for almost two years and there were no problem so far. > What happens when you use libvirt/virt-manager? I didn't have libvirt installed, because I was using only qemu-kvm with my own scripts. Anyway, I've installed it and tried to boot new virtual machine a few times and it was working fine, but this bug happens only occasionally and I was not able to reproduce it (before I installed libvirt) using qemu-kvm command from the reproducer neither.
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. It has been denied for the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. **
This rawhide image you are using, is that something you installed yourself, or was it downloaded from somewhere? Do you see this crash with other image files, or only with this specific image? It seems to be crashing in the early stage of launching qemu, in a call to qemu_mem_alloc() from pc_init1().
(In reply to comment #6) > This rawhide image you are using, is that something you installed yourself, > or was it downloaded from somewhere? I've installed using pxe and blank image > Do you see this crash with other image files, or only with this specific image? I've seen it with rhel5 image too (I don't use other than rawhide and rhel5 images too often)
Are you low on memory when this problem happens? It sounds like it is unrelated to the image you use, which also matches where it crashes in the code.
(In reply to comment #8) > Are you low on memory when this problem happens? I'm not sure, but I don't think so. My machine has 4GB ram and no swap. I'm not running anything consuming too much memory except firefox. I'm reserving 1G for VM and I've tried I can use 2 VMs without any problem, so I guess there should be enough memory when running only 1 VM, but I don't know if qemu takes that 1 GB of memory immediately or only allocates it when needed.
Testing this with the most recent build: http://qafiler.bos.redhat.com/redhat/nightly/RHEL6.0-20100722.n.0/6.0/Server/x86_64/iso/RHEL6.0-20100722.n.0-Server-x86_64-DVD1.iso and with an installed guest of the same, I did not see the failure reported above. However a number of differences exist including use of the latest rhel6.0 build, guest image, and host environment. Concerning the failure, puzzling the dump and source it appears posix_memalign(3) is returning !0 to osdep.c:qemu_memalign() which is calling abort(). So this is an internal integrity check rather than qemu stumbling on a bad address AFAICT. The only documented return from posix_memalign() which appears possible given the code is ENOMEM. EINVAL appears to not be possible as the alignment is a fixed at: ./exec.c:#define PREFERRED_RAM_ALIGN (2*1024*1024) So this may have been a transient failure due to host memory unavailability. If you are still able to create the failure, it would be helpful to check whether you are indeed hitting a host memory limitation at the time it occurs. Also if this problem persists, could you make the "rawhide.x86_64.img" available? That would help narrow down the problem space.
I can't test it right now, so I will test it on Monday
4GB of RAM isn't a whole lot if you are using Firefox and GNOME or KDE. Try adding some swap and see if persists. Per John's posting, this is the host that is out of suitable memory. I don't think this is a bug.
Odd, I was able to run two machines doing yum update without swap and it was working fine but next time I was not able to start any vm at all and there were the same other applications running. Anyway, I've created 8GB swap and was not able to reproduce this crash after swapon. So most probably some application just started to use much more memory than before, because it used to work fine in F-12.