This patchset fixes a couple of minor memory leaks I found by running
"make check" for the arm targets with the clang leak sanitizer enabled.

The first two patches are necessary because there are a few leaks
that are either not interesting to fix or which are not in our code,
and which otherwise clutter up the logs with failure messages.
We have a suppressions-file already, but it's in the scripts/oss-fuzz
subdirectory, so I move it out as it's more widely useful than that,
and add some more suppression lines to it.

Patches 3 and 4 are the actual leak fixes, which are straightforward.

This gets me what would be a clean run, except that there's something
wrong with the refcounting of qio channel objects in the chardev code,
which results in variously use-after-free, leak, or assertion failures
when running the vhost-user tests in qos-test. I'm still looking at
those, but in the meantime posting this series gives me something to
point at as part of the repro instructions for those errors.

thanks
-- PMM

Peter Maydell (4):
  scripts: Move lsan_suppressions.txt out of oss-fuzz subdir
  scripts/lsan_suppressions.txt: Add more leaks
  hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()
  tests/qtest/iommu-smmuv3-test: Free QPCIDevice

 .gitlab-ci.d/buildtest.yml             |  2 +-
 hw/gpio/aspeed_gpio.c                  |  2 +-
 scripts/lsan_suppressions.txt          | 31 ++++++++++++++++++++++++++
 scripts/oss-fuzz/lsan_suppressions.txt |  5 -----
 tests/qtest/iommu-smmuv3-test.c        |  1 +
 5 files changed, 34 insertions(+), 7 deletions(-)
 create mode 100644 scripts/lsan_suppressions.txt
 delete mode 100644 scripts/oss-fuzz/lsan_suppressions.txt

-- 
2.43.0

Peter Maydell <peter.maydell@linaro.org> writes:

> This patchset fixes a couple of minor memory leaks I found by running
> "make check" for the arm targets with the clang leak sanitizer enabled.
>
> The first two patches are necessary because there are a few leaks
> that are either not interesting to fix or which are not in our code,
> and which otherwise clutter up the logs with failure messages.
> We have a suppressions-file already, but it's in the scripts/oss-fuzz
> subdirectory, so I move it out as it's more widely useful than that,
> and add some more suppression lines to it.
>
> Patches 3 and 4 are the actual leak fixes, which are straightforward.
>
> This gets me what would be a clean run, except that there's something
> wrong with the refcounting of qio channel objects in the chardev code,
> which results in variously use-after-free, leak, or assertion failures
> when running the vhost-user tests in qos-test. I'm still looking at
> those, but in the meantime posting this series gives me something to
> point at as part of the repro instructions for those errors.
>

Looks like something I worked on in the past. It seems this fell through
the cracks:

https://lore.kernel.org/r/20250515222014.4161-1-farosas@suse.de

On Fri, 27 Feb 2026 at 18:52, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > This patchset fixes a couple of minor memory leaks I found by running
> > "make check" for the arm targets with the clang leak sanitizer enabled.
> >
> > The first two patches are necessary because there are a few leaks
> > that are either not interesting to fix or which are not in our code,
> > and which otherwise clutter up the logs with failure messages.
> > We have a suppressions-file already, but it's in the scripts/oss-fuzz
> > subdirectory, so I move it out as it's more widely useful than that,
> > and add some more suppression lines to it.
> >
> > Patches 3 and 4 are the actual leak fixes, which are straightforward.
> >
> > This gets me what would be a clean run, except that there's something
> > wrong with the refcounting of qio channel objects in the chardev code,
> > which results in variously use-after-free, leak, or assertion failures
> > when running the vhost-user tests in qos-test. I'm still looking at
> > those, but in the meantime posting this series gives me something to
> > point at as part of the repro instructions for those errors.
> >
>
> Looks like something I worked on in the past. It seems this fell through
> the cracks:
>
> https://lore.kernel.org/r/20250515222014.4161-1-farosas@suse.de

Yeah, that looks very familiar. The way it only reproduces in
a loaded system is fantastically annoying -- it relatively
reliably falls over in a full "make -j20 check" run for me
but I had massive trouble trying to get anything to reliably
repro in a useful way...

The vhost-user-test also seems to be doing some odd things itself:
for instance the wait_for_fds() function assumes there is RAM at
0x0, but we run the test on the arm virt board where RAM doesn't
start at that address. Presumably we should either make the test
handle that or else restrict it to not run on boards where it
will never work.

I'll have a go with your patches and see if I still see issues.

-- PMM