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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
