Re: [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks.

[Peter Maydell]

On Sun, 8 Mar 2020 at 11:58, Mark Cave-Ayland
<address@hidden> wrote:
> I just tried this patchset applied on top of git master and it causes 
> qemu-system-ppc
> to segfault on startup:
>
> $ gdb --args ./qemu-system-ppc
> ...
> ...
> Thread 1 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
> 0x0000555555e7e38c in timer_del (ts=0x0) at util/qemu-timer.c:429
> 429         QEMUTimerList *timer_list = ts->timer_list;
> (gdb) bt
> #0  0x0000555555e7e38c in timer_del (ts=0x0) at util/qemu-timer.c:429
> #1  0x0000555555b5d2c1 in mos6522_reset (dev=0x555556e0ac50) at 
> hw/misc/mos6522.c:468
> #2  0x0000555555b63570 in mos6522_cuda_reset (dev=0x555556e0ac50) at
> hw/misc/macio/cuda.c:599

It looks like we haven't caught all the cases of "somebody created a
MOS6522 (or one of its subclasses) but forgot to realize it". This
particular one I think is the s->cuda which is inited in macio_oldworld_init()
but not realized in macio_oldworld_realize(). I think that pmu_init() in
hw/misc/macio/pmu.c also has this bug. We need to go through and
audit all the places where we create TYPE_MOS6522 or any of its
subclasses and make sure they are also realizing the devices they create.
(The presence of the new 3-phase reset infrastructure in the backtrace
is a red herring here -- this would have crashed the same way with the
old code too.)

We should probably find some generic place in Device code where we
can stick an assert "are we trying to reset an unrealized device?"
because I bet we have other instances of this bug which we haven't
noticed because the reset function happens to not misbehave on
an inited-but-not-realized device...

thanks
-- PMM