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-kvm | Assignee: | Gerd Hoffmann <kraxel> | ||||
Status: | CLOSED WORKSFORME | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.2 | CC: | 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: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Xiaoqing Wei
2011-09-22 07:08:41 UTC
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. |