[Qemu-devel] qemu-kvm 0.12.2 VNC segfault

[Chris Webb <chris@arachsys.com>]

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.