Re: qemu-kvm segfaults in qemu_del_timer (0.10.5 and 0.10.6)

[Avi Kivity <avi@redhat.com>]

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