From: Peter Maydell <peter.maydell@linaro.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Euler Robot <euler.robot@huawei.com>,
Pan Nengyuan <pannengyuan@huawei.com>,
QEMU Developers <qemu-devel@nongnu.org>,
zhanghailiang <zhang.zhanghailiang@huawei.com>
Subject: Re: [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks.
Date: Sun, 8 Mar 2020 13:39:28 +0000 [thread overview]
Message-ID: <CAFEAcA_8SWR6MrNL98GFNASs0_qE_U4pgiw_LyiydKVaSb7C8A@mail.gmail.com> (raw)
In-Reply-To: <8af2cdaa-7e3e-409f-5351-7fc54e00aab5@ilande.co.uk>
On Sun, 8 Mar 2020 at 11:58, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> 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
next prev parent reply other threads:[~2020-03-08 13:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-05 6:54 [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks Pan Nengyuan
2020-03-05 6:46 ` no-reply
2020-03-05 6:54 ` [PATCH v4 1/3] s390x: fix memleaks in cpu_finalize Pan Nengyuan
2020-03-05 8:34 ` David Hildenbrand
2020-03-05 9:03 ` Pan Nengyuan
2020-03-05 6:54 ` [PATCH v4 2/3] mac_via: fix incorrect creation of mos6522 device in mac_via Pan Nengyuan
2020-03-05 7:10 ` Pan Nengyuan
2020-03-05 7:18 ` Pan Nengyuan
2020-03-08 13:29 ` Peter Maydell
2020-03-09 0:56 ` Pan Nengyuan
2020-03-09 9:21 ` Peter Maydell
2020-03-09 10:02 ` Pan Nengyuan
2020-03-09 10:10 ` Peter Maydell
2020-03-09 12:34 ` Markus Armbruster
2020-03-09 12:51 ` Pan Nengyuan
2020-03-09 14:14 ` Markus Armbruster
2020-03-09 16:16 ` Mark Cave-Ayland
2020-03-10 0:34 ` Pan Nengyuan
2020-03-10 9:07 ` Markus Armbruster
2020-03-10 9:41 ` Peter Maydell
2020-03-10 12:38 ` BALATON Zoltan
2020-03-14 13:19 ` Mark Cave-Ayland
2020-03-14 14:03 ` Paolo Bonzini
2020-03-15 14:56 ` Markus Armbruster
2020-03-15 17:58 ` Paolo Bonzini
2020-03-16 6:03 ` Markus Armbruster
2020-03-16 8:43 ` Paolo Bonzini
2020-03-18 13:02 ` Markus Armbruster
2020-03-18 13:21 ` Paolo Bonzini
2020-03-18 14:58 ` Peter Maydell
2020-03-18 15:06 ` Markus Armbruster
2020-03-18 16:44 ` Paolo Bonzini
2020-03-19 7:01 ` Markus Armbruster
2020-03-19 8:43 ` Paolo Bonzini
2020-04-02 13:40 ` Markus Armbruster
2020-03-15 15:16 ` Markus Armbruster
2020-03-05 6:54 ` [PATCH v4 3/3] hw/misc/mos6522: move timer_new from init() into realize() to avoid memleaks Pan Nengyuan
2020-03-05 22:56 ` David Gibson
2020-03-06 0:50 ` Pan Nengyuan
2020-03-13 6:50 ` David Gibson
2020-03-08 11:58 ` [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks Mark Cave-Ayland
2020-03-08 13:39 ` Peter Maydell [this message]
2020-03-09 0:49 ` Pan Nengyuan
2020-03-09 16:14 ` Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA_8SWR6MrNL98GFNASs0_qE_U4pgiw_LyiydKVaSb7C8A@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=euler.robot@huawei.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=pannengyuan@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).