Bug 518476 - /usr/bin/qemu-kvm: malloc(): memory corruption
Summary: /usr/bin/qemu-kvm: malloc(): memory corruption
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 11
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Glauber Costa
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-20 14:48 UTC by Tom Horsley
Modified: 2009-11-20 19:39 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-20 19:39:04 UTC
Type: ---

Attachments (Terms of Use)

Description Tom Horsley 2009-08-20 14:48:52 UTC
Description of problem:

My KVM host is a dual 4-core xeon system:

[root@godzilla qemu]# virsh nodeinfo
CPU model:           x86_64
CPU(s):              8
CPU frequency:       2664 MHz
CPU socket(s):       2
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         2033636 kB

I installed an i386 ubuntu 9.04 virtual system using the "alternate" text mode
CD installer and virt-manager, and shortly after the first boot following the
install, everything froze up. The VM console was all black with a white
area where the login would be typed, but it never finished rendering the
complete login screen. The virt-manager app running on the host was frozen
as well, and even the ssh session where I was logged into the host appeared
frozen. It seemed like the host was down from where I sat.

I eventually found the host console was working fine, did a kill -9 on
the qemu-kvm process that was running the ubuntu VM, and everything
appeared to start working again, and I found this in the qemu log:

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name testubu9d04i -uuid 3b57c17d-4e5b-9a6b-afd5-93189c948633 -monitor pty -pidfile /var/run/libvirt/qemu//testubu9d04i.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/testubu9d04i.img,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:49:6f:32,vlan=0,model=virtio -net tap,fd=18,vlan=0 -serial pty -parallel none -usb -vnc -soundhw es1370 
char device redirected to /dev/pts/1
char device redirected to /dev/pts/2
audio: Failed to create voice `es1370.adc'
audio: Failed to create voice `es1370.adc'
*** glibc detected *** /usr/bin/qemu-kvm: malloc(): memory corruption: 0x00007f7cbc0ea470 ***

Version-Release number of selected component (if applicable):


How reproducible:

I'm afraid it isn't very reproducible at all. On other time when I booted the
same VM, the VM itself crashed at boot time with no error message showing up,
and since then the VM seems to be working fine.

Steps to Reproduce:
1. see above for what it is worth
Actual results:

freezing and memory corruption errors

Expected results:

vm just runs normally.

Additional info:

Comment 1 Tom Horsley 2009-08-20 15:55:10 UTC
This may have something to do with the video. Any time it does flake out,
it always seems to happen at the same instant as the ubuntu graphical
boot screen is being replaced with the X login screen. I have also seen
vncviewers crash when talking to ubuntu consoles on a Xen box at that
same time. Something weird ubuntu does with the video maybe that the
qemu video emulation gets confused by?

Comment 2 Mark McLoughlin 2009-08-21 07:57:35 UTC
Okay, we really need a stack trace here to have any hope of figuring out what the problem here is

Can you 'gdb /usr/bin/qemu-kvm <pid-of-qemu-process>' and do 'thread apply all bt full' ?

It would be best to have qemu-debuginfo installed before doing that

If I was to point fingers, I'd blame the vnc server code. e.g. we already know about bug #501131

Comment 3 Tom Horsley 2009-08-21 11:51:49 UTC
I assume you mean a stack trace from a time when it has flaked out,
not just any old time? That could be difficult since it hardly ever
happens, but I can get the debuginfo installed in case it does
happen again.

Comment 4 Mark McLoughlin 2009-08-21 12:00:51 UTC
(In reply to comment #3)
> I assume you mean a stack trace from a time when it has flaked out,
> not just any old time? 


> That could be difficult since it hardly ever happens

Yeah, unfortunately there's not much we can do about it until we have some idea where the problem is

> but I can get the debuginfo installed in case it does happen again.  


Comment 5 Mark McLoughlin 2009-11-20 19:39:04 UTC
No response to needinfo since 2009-08-21, closing

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