[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] qemu-kvm 0.12.2 VNC segfault
From: |
Chris Webb |
Subject: |
[Qemu-devel] qemu-kvm 0.12.2 VNC segfault |
Date: |
Sun, 21 Feb 2010 17:23:59 +0000 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
I've just had a segfault from one of the qemu-kvm virtual machines we run.
This is qemu-kvm 0.12.2 running with the in-kernel kvm modules on linux
2.6.32.7 on a dual quad-core Xeon E5420 machine, with ksm enabled.
The backtrace looks like
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c:908
#1 0x00000000004c015b in vnc_refresh (opaque=<value optimized out>) at
vnc.c:2305
#2 0x0000000000405f50 in qemu_run_timers (ptimer_head=0x836cc0,
current_time=1606536889) at /packages/qemu-kvm-0.12/src-gktOMQ/vl.c:1127
#3 0x0000000000408edf in main_loop_wait (timeout=1000) at
/packages/qemu-kvm-0.12/src-gktOMQ/vl.c:4036
#4 0x0000000000421d7a in kvm_main_loop () at
/packages/qemu-kvm-0.12/src-gktOMQ/qemu-kvm.c:2121
#5 0x000000000040b755 in main (argc=<value optimized out>,
argv=0x7fffcc2fa1b8, envp=<value optimized out>) at
/packages/qemu-kvm-0.12/src-gktOMQ/vl.c:4209
and the segfault itself is rather puzzling.
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c:908
908 if (vs->need_update && vs->csock != -1) {
(gdb) p vs
$1 = (VncState *) 0x83f0
(gdb) p *vs
Cannot access memory at address 0x83f0
The call site in vnc_refresh() looks like:
vs = vd->clients;
while (vs != NULL) {
rects += vnc_update_client(vs, has_dirty);
vs = vs->next;
}
but when I go up a stack frame and look at the vd over which this loop would be
iterating:
(gdb) up
#1 0x00000000004c015b in vnc_refresh (opaque=<value optimized out>) at
vnc.c:2305
2305 rects += vnc_update_client(vs, has_dirty);
(gdb) p *vd->clients
$2 = {csock = 17, ds = 0x19b2760, dirty = {{0, 0, 0, 0} <repeats 293 times>,
{50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {50331648, 0, 0,
0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216,
0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0},
{16777216, 0, 0, 0}, {50331648, 0, 0, 0}, {0, 0, 0, 0} <repeats 1742 times>},
vd = 0x1ef60b0, need_update = 0, force_update = 0, features = 0, absolute = 0,
last_x = -1, last_y = -1, vnc_encoding = 0, tight_quality = 0 '\0',
tight_compression = 0 '\0', major = 0, minor = 0, challenge = '\0' <repeats 15
times>, output = {capacity = 1036, offset = 0, buffer = 0x1ec7420 "RFB
003.008\n¦\177"}, input = {capacity = 0, offset = 0, buffer = 0x0},
write_pixels = 0, send_hextile_tile = 0, clientds = {flags = 0 '\0', width = 0,
height = 0, linesize = 0, data = 0x0, pf = {bits_per_pixel = 0 '\0',
bytes_per_pixel = 0 '\0', depth = 0 '\0', rmask = 0, gmask = 0, bmask = 0,
amask = 0, rshift = 0 '\0', gshift = 0 '\0', bshift = 0 '\0', ashift = 0 '\0',
rmax = 0 '\0', gmax = 0 '\0', bmax = 0 '\0', amax = 0 '\0', rbits = 0 '\0',
gbits = 0 '\0', bbits = 0 '\0', abits = 0 '\0'}}, audio_cap = 0x0, as = {freq =
44100, nchannels = 2, fmt = AUD_FMT_S16, endianness = 0}, read_handler =
0x4bdb30 <protocol_version>, read_handler_expect = 12, modifiers_state = '\0'
<repeats 255 times>, zlib = {capacity = 0, offset = 0, buffer = 0x0}, zlib_tmp
= {capacity = 0, offset = 0, buffer = 0x0}, zlib_stream = {{next_in = 0x0,
avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg =
0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler =
0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0,
opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in
= 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0,
state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0,
reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0,
opaque = 0x0, data_type = 0, adler = 0, reserved = 0}}, next = 0x0}
(gdb) p vd->clients.next
$3 = (VncState *) 0x0
So the first client in vd is fine, and the next pointer is set to zero, not
0x83f0.
Some sort of race where a client disconnects and is removed from the client
list while the vnc_refresh() loop is iterating over it, maybe?
Cheers,
Chris.
- [Qemu-devel] qemu-kvm 0.12.2 VNC segfault,
Chris Webb <=