From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MbZdt-0003Pp-8b
	for qemu-devel@nongnu.org; Thu, 13 Aug 2009 08:42:53 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MbZdn-0003J5-Jz
	for qemu-devel@nongnu.org; Thu, 13 Aug 2009 08:42:52 -0400
Received: from [199.232.76.173] (port=44292 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MbZdn-0003Ik-6k
	for qemu-devel@nongnu.org; Thu, 13 Aug 2009 08:42:47 -0400
Received: from mx2.redhat.com ([66.187.237.31]:55778)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MbZdm-0004NN-Os
	for qemu-devel@nongnu.org; Thu, 13 Aug 2009 08:42:47 -0400
Message-ID: <4A840A3E.1040400@redhat.com>
Date: Thu, 13 Aug 2009 15:42:38 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <20090812150159.GW5348@arachsys.com> <4A82E200.3040107@redhat.com>
	<20090812162401.GB8115@arachsys.com>
	<20090813122333.GA2863@arachsys.com>
In-Reply-To: <20090813122333.GA2863@arachsys.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: qemu-kvm segfaults in qemu_del_timer (0.10.5 and
	0.10.6)
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: Chris Webb <chris@arachsys.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org

On 08/13/2009 03:23 PM, Chris Webb wrote:
> We've been lucky and relatively quickly got a core dump from one of the new
> qemu-kvms with the non-zero core file rlimit. A backtrace looks like this:
>
>    (gdb) bt
>    #0  0x00000000004068f7 in qemu_mod_timer (ts=0x30d1f30, expire_time=430489)
>        at /packages/qemu-kvm/src-f39tF1/vl.c:1161
>    #1  0x0000000000495dd5 in vnc_update_client (opaque=<value optimized out>) at vnc.c:765
>    #2  0x00000000004081da in main_loop_wait (timeout=<value optimized out>) at /packages/qemu-kvm/src-f39tF1/vl.c:1240
>    #3  0x000000000051613a in kvm_main_loop () at /packages/qemu-kvm/src-f39tF1/qemu-kvm.c:596
>    #4  0x000000000040c7b7 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>)
>        at /packages/qemu-kvm/src-f39tF1/vl.c:3850
>
> The segfault appears to be a null pointer dereference. ts->clock is NULL
> and line 1161 uses ts->clock->type:
>
>    (gdb) p ts
>    $4 = (QEMUTimer *) 0x30d1f30
>    (gdb) p ts->clock
>    $5 = (QEMUClock *) 0x0
>
> The VncState in vnc_update_client is as follows:
>
>    (gdb) f 1
>    #1  0x0000000000495dd5 in vnc_update_client (opaque=<value optimized out>) at vnc.c:765
>    765             qemu_mod_timer(vs->timer, qemu_get_clock(rt_clock) + VNC_REFRESH_INTERVAL);
>    (gdb) p *vs
>    $12 = {timer = 0x30d1f30, csock = -986235208,

csock looks corrupted, should be -1 or an fd.  Was a vnc client connected?

Was the guest playing with the display resolution?

> ds = 0x0, vd = 0x0, need_update = 1, dirty_row = {{0, 0, 4294967295,
>          4294967295}<repeats 768 times>, {4294967295, 4294967295, 4294967295, 4294967295}<repeats 1280 times>},
>      old_data = 0x7f9b8276f010<Address 0x7f9b8276f010 out of bounds>,

old_data is also corrupted according to gdb, though it seems sane.


-- 
error compiling committee.c: too many arguments to function