On Mon, 9 Mar 2026 at 12:06, Fabiano Rosas <[email protected]> wrote: > > Peter Maydell <[email protected]> writes: > > > I'm continuing to work through leaks reported during "make check". > > Some of them come from the migration-test. (For these to actually > > appear in the log you need to run with QTEST_LOG=1, otherwise the > > migration test framework will send stderr to /dev/null and the > > tests will fail without printing the leak report.) > > I'm pretty sure something changed that caused this. In the past the > leaks would be reported by the parent migration-test binary, so it > wouldn't matter where QEMU sends stderr. I don't know if it's QEMU's > build environment or something on my machine.
I think this depends on the kind of leak. If it's a leak in the test binary itself (migration-test) then that will get reported in the logs. If it's a leak in the QEMU process that the test starts, then it depends on what migration-test decides to do with that process's stderr. The leaks below are all from QEMU proper, not the test binary. > > The issue with this is that it means we need to suppress leak > > reports in the whole migration-test binary, which means the > > migration code will get no leak-detection coverage at all. > > (Not all the leak paths have qmp_migrate_incoming() in their backtrace, > > as you can see below.) > > > > We're getting pretty close to being able to get a complete "make check" > > run with the leak sanitizer enabled, so it would be nice to not have > > to suppress leak reports for this test at some point. > > > > Go team! Let me just put the migration pull-request out and I'll look > into this. Thanks; that would be great, because I think some of these leaks would be tricky to suppress via the scripts/lsan_suppressions.txt file -- they don't come from migration-test itself so a suppression based on the binary filename wouldn't match, and while some of the reported backtraces go through functions like migration_connect_incoming() that we could put in a suppression for, some of them (like the first one quoted) don't go through any migration-specific function, so there's no obvious function to add a suppression for. -- PMM
