Bug 740468 - qemu-kvm core dumps when win7-64 guest equipped with intel-hda audio rebooting
Summary: qemu-kvm core dumps when win7-64 guest equipped with intel-hda audio rebooting
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-22 07:08 UTC by Xiaoqing Wei
Modified: 2013-01-10 00:22 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-03-16 13:37:35 UTC
Target Upstream Version:

Attachments (Terms of Use)
gdb-bt (8.54 KB, text/plain)
2011-09-22 07:09 UTC, Xiaoqing Wei
no flags Details

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

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]

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

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.


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.

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