From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NjFXK-0007Bd-Dh
	for qemu-devel@nongnu.org; Sun, 21 Feb 2010 12:24:06 -0500
Received: from [199.232.76.173] (port=54281 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NjFXK-0007B6-2s
	for qemu-devel@nongnu.org; Sun, 21 Feb 2010 12:24:06 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <chris@arachsys.com>) id 1NjFXI-00025f-3a
	for qemu-devel@nongnu.org; Sun, 21 Feb 2010 12:24:05 -0500
Received: from alpha.arachsys.com ([91.203.57.7]:42209)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <chris@arachsys.com>) id 1NjFXH-000251-Gi
	for qemu-devel@nongnu.org; Sun, 21 Feb 2010 12:24:03 -0500
Date: Sun, 21 Feb 2010 17:23:59 +0000
From: Chris Webb <chris@arachsys.com>
Message-ID: <20100221172358.GH4894@arachsys.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] qemu-kvm 0.12.2 VNC segfault
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org

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=3D0x83f0, has_dirty=3D18) at vnc.c:908
  #1  0x00000000004c015b in vnc_refresh (opaque=3D<value optimized out>) at=
 vnc.c:2305
  #2  0x0000000000405f50 in qemu_run_timers (ptimer_head=3D0x836cc0, curren=
t_time=3D1606536889) at /packages/qemu-kvm-0.12/src-gktOMQ/vl.c:1127
  #3  0x0000000000408edf in main_loop_wait (timeout=3D1000) at /packages/qe=
mu-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=3D<value optimized out>, argv=3D0x7f=
ffcc2fa1b8, envp=3D<value optimized out>) at /packages/qemu-kvm-0.12/src-gk=
tOMQ/vl.c:4209

and the segfault itself is rather puzzling.

  #0  vnc_update_client (vs=3D0x83f0, has_dirty=3D18) at vnc.c:908
  908         if (vs->need_update && vs->csock !=3D -1) {
  (gdb) p vs
  $1 =3D (VncState *) 0x83f0
  (gdb) p *vs
  Cannot access memory at address 0x83f0

The call site in vnc_refresh() looks like:

  vs =3D vd->clients;
  while (vs !=3D NULL) {
      rects +=3D vnc_update_client(vs, has_dirty);
      vs =3D vs->next;                           =20
  }

but when I go up a stack frame and look at the vd over which this loop woul=
d be
iterating:

  (gdb) up
  #1  0x00000000004c015b in vnc_refresh (opaque=3D<value optimized out>) at=
 vnc.c:2305
  2305            rects +=3D vnc_update_client(vs, has_dirty);
  (gdb) p *vd->clients    =20
  $2 =3D {csock =3D 17, ds =3D 0x19b2760, dirty =3D {{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}, {16=
777216, 0, 0, 0}, {16777216, 0, 0, 0}, {50331648, 0, 0, 0}, {0, 0, 0, 0} <r=
epeats 1742 times>}, vd =3D 0x1ef60b0, need_update =3D 0, force_update =3D =
0, features =3D 0, absolute =3D 0, last_x =3D -1, last_y =3D -1, vnc_encodi=
ng =3D 0, tight_quality =3D 0 '\0', tight_compression =3D 0 '\0', major =3D=
 0, minor =3D 0, challenge =3D '\0' <repeats 15 times>, output =3D {capacit=
y =3D 1036, offset =3D 0, buffer =3D 0x1ec7420 "RFB 003.008\n=A6\177"}, inp=
ut =3D {capacity =3D 0, offset =3D 0, buffer =3D 0x0}, write_pixels =3D 0, =
send_hextile_tile =3D 0, clientds =3D {flags =3D 0 '\0', width =3D 0, heigh=
t =3D 0, linesize =3D 0, data =3D 0x0, pf =3D {bits_per_pixel =3D 0 '\0', b=
ytes_per_pixel =3D 0 '\0', depth =3D 0 '\0', rmask =3D 0, gmask =3D 0, bmas=
k =3D 0, amask =3D 0, rshift =3D 0 '\0', gshift =3D 0 '\0', bshift =3D 0 '\=
0', ashift =3D 0 '\0', rmax =3D 0 '\0', gmax =3D 0 '\0', bmax =3D 0 '\0', a=
max =3D 0 '\0', rbits =3D 0 '\0', gbits =3D 0 '\0', bbits =3D 0 '\0', abits=
 =3D 0 '\0'}}, audio_cap =3D 0x0, as =3D {freq =3D 44100, nchannels =3D 2, =
fmt =3D AUD_FMT_S16, endianness =3D 0}, read_handler =3D 0x4bdb30 <protocol=
_version>, read_handler_expect =3D 12, modifiers_state =3D '\0' <repeats 25=
5 times>, zlib =3D {capacity =3D 0, offset =3D 0, buffer =3D 0x0}, zlib_tmp=
 =3D {capacity =3D 0, offset =3D 0, buffer =3D 0x0}, zlib_stream =3D {{next=
_in =3D 0x0, avail_in =3D 0, total_in =3D 0, next_out =3D 0x0, avail_out =
=3D 0, total_out =3D 0, msg =3D 0x0, state =3D 0x0, zalloc =3D 0, zfree =3D=
 0, opaque =3D 0x0, data_type =3D 0, adler =3D 0, reserved =3D 0}, {next_in=
 =3D 0x0, avail_in =3D 0, total_in =3D 0, next_out =3D 0x0, avail_out =3D 0=
, total_out =3D 0, msg =3D 0x0, state =3D 0x0, zalloc =3D 0, zfree =3D 0, o=
paque =3D 0x0, data_type =3D 0, adler =3D 0, reserved =3D 0}, {next_in =3D =
0x0, avail_in =3D 0, total_in =3D 0, next_out =3D 0x0, avail_out =3D 0, tot=
al_out =3D 0, msg =3D 0x0, state =3D 0x0, zalloc =3D 0, zfree =3D 0, opaque=
 =3D 0x0, data_type =3D 0, adler =3D 0, reserved =3D 0}, {next_in =3D 0x0, =
avail_in =3D 0, total_in =3D 0, next_out =3D 0x0, avail_out =3D 0, total_ou=
t =3D 0, msg =3D 0x0, state =3D 0x0, zalloc =3D 0, zfree =3D 0, opaque =3D =
0x0, data_type =3D 0, adler =3D 0, reserved =3D 0}}, next =3D 0x0}
  (gdb) p vd->clients.next=20
  $3 =3D (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.