Hide Forgot
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
Created attachment 524329 [details] gdb-bt
Does it reproduce reliable? Or did it happen just once? Do you still have the core dump?
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.
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.