Bug 518476

Summary:	/usr/bin/qemu-kvm: malloc(): memory corruption
Product:	[Fedora] Fedora	Reporter:	Tom Horsley <horsley1953>
Component:	qemu	Assignee:	Glauber Costa <gcosta>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	11	CC:	berrange, clalance, dwmw2, ehabkost, gcosta, itamar, jaswinder, markmc, quintela, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-11-20 19:39:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 127.0.0.1:0 -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):

qemu-system-x86-0.10.5-3.fc11.x86_64
qemu-kvm-tools-0.10.5-3.fc11.x86_64
qemu-kvm-0.10.5-3.fc11.x86_64

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? 

Yep

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

thanks

Comment 5 Mark McLoughlin 2009-11-20 19:39:04 UTC

No response to needinfo since 2009-08-21, closing