Bug 740468

Summary: qemu-kvm core dumps when win7-64 guest equipped with intel-hda audio rebooting
Product: Red Hat Enterprise Linux 6 Reporter: Xiaoqing Wei <xwei>
Component: qemu-kvmAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED WORKSFORME QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: acathrow, areis, juzhang, michen, mkenneth, qzhou, shuang, tburke, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-16 13:37:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
gdb-bt none

Description Xiaoqing Wei 2011-09-22 07:08:41 UTC
Description of problem:
qemu-kvm core dumps when win7-64 guest equipped with intel-hda audio rebooting

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.192.el6.x86_64

How reproducible:
only once

Steps to Reproduce:
1. boot win7-64 with "  -device intel-hda -device hda-output"
2. reboot guest
3. spicec -h xxx -p xxx
4. disconnect by "killall -9 spicec"
5. redo  3-4 
Actual results:
qemu-kvm core dumps

Expected results:
qemu-kvm works well

Additional info:

host kernel 2.6.32-198.el6.x86_64

full cmd:
qemu-kvm -name win7-64 -monitor stdio -chardev socket,id=serial_id_20110921-201713-lHXA,path=/tmp/serial-20110921-201713-lHXA,server,nowait -device isa-serial,chardev=serial_id_20110921-201713-lHXA -drive file='/root/staf-kvm-devel/autotest-devel/client/tests/kvm/images/win7-64.qcow2',index=0,if=none,id=drive-ide0-0-0,media=disk,cache=none,format=qcow2,aio=native -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device rtl8139,netdev=iddiR3cm,mac=9a:39:f1:b4:51:14,id=ndev00iddiR3cm,bus=pci.0,addr=0x3 -netdev tap,id=iddiR3cm,vhost=on,ifname='t0-201713-lHXA',script='/root/staf-kvm-devel/autotest-devel/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 8192 -smp 4,cores=2,threads=1,sockets=2  -cpu cpu64-rhel6,+sse2,+x2apic  -spice port=8064,disable-ticketing -vga qxl -rtc base=localtime,clock=host,driftfix=none -boot order=cdn,once=d,menu=off     -M rhel6.2.0 -usb -usbdevice tablet -enable-kvm \
\
\
 -device intel-hda -device hda-output

Comment 1 Xiaoqing Wei 2011-09-22 07:09:48 UTC
Created attachment 524329 [details]
gdb-bt

Comment 3 Gerd Hoffmann 2011-10-10 10:05:52 UTC
Does it reproduce reliable?
Or did it happen just once?
Do you still have the core dump?

Comment 5 Gerd Hoffmann 2011-10-14 08:57:00 UTC
Program terminated with signal 11, Segmentation fault.
#0  clip_natural_int16_t_from_stereo (dst=<value optimized out>, src=<value optimized out>, 
    samples=<value optimized out>) at audio/mixeng_template.h:158
158             *out++ = glue (clip_, ET) (in->l);
(gdb) up
#1  0x00000000004d25aa in line_out_run (hw=0x1180ac0, live=<value optimized out>)
    at audio/spiceaudio.c:160
160                 hw->clip (out->fpos, hw->mix_buf + rpos, len);
(gdb) print *out
$1 = {hw = {enabled = 1, poll_mode = 0, pending_disable = 0, info = {bits = 16, sign = 1, 
      freq = 44100, nchannels = 2, align = 3, shift = 2, bytes_per_second = 176400, 
      swap_endianness = 0}, clip = 0x4d11c0 <clip_natural_int16_t_from_stereo>, rpos = 384, 
    ts_helper = 25984, mix_buf = 0x3988010, samples = 1024, sw_head = {lh_first = 0x1180a10}, 
    cap_head = {lh_first = 0x0}, pcm_ops = 0x8eab00, entries = {le_next = 0x0, 
      le_prev = 0xc74348}}, sin = {base = {sif = 0x64f920}, st = 0x1180b90}, rate = {
    start_ticks = 176436432847, bytes_sent = 109888}, active = 1, frame = 0x3fe349c, 
  fpos = 0x3fe369c, fsize = 128}
(gdb) print *out->frame
Cannot access memory at address 0x3fe349c
(gdb) print *out->fpos
Cannot access memory at address 0x3fe369c
(gdb) 

out->frame and out->fpos point into nowhere.  The values look sensible though.  fpos = frame + 512 bytes (128 samples).  fsize is 128 (samples).  The 1024 byte (256 samples) buffer handed out by spice_server_playback_get_buffer() is half-filled.

The big question is why the pointers are invalid now?  Looks like use-after-free at first glance.  spice-server doesn't allocate+release buffers though, they are allocated at interface creation time, then kept for the whole interface life time.  I have no idea how use-after-free could possibly happen.

Trying to reproduce the issue locally failed too.  Constantly reconnecting the spice client every few seconds while playing music within the VM and rebooting it now and then.  Nothing, runs rock solid.

Hmm.

Comment 9 Gerd Hoffmann 2012-03-16 13:37:35 UTC
Happened once, not reproducible, not clear what the root cause is or was, not clear whenever this still exists (might be a memory corruption bug fixed meanwhile). Closing.