On Sun, 8 Mar 2026 at 23:39, Pierrick Bouvier
<[email protected]> wrote:
>
> On 3/8/26 1:01 PM, Peter Maydell wrote:
> > The clang/gcc address sanitizers intercept calls to mlock() and
> > make them do nothing, because mlock doesn't play nicely with the
> > huge allocations the sanitizers do. This means that the functional
> > test x86_64/test_memlock.py fails, because it looks in /proc/ to
> > see if the binary actually locked anything, and fails because it
> > sees 0 pages locked.
> >
> > What would be a good way to skip this test in this situation?
> >
> > (1) Should we make QEMU's mem-lock related command line options
> > actively fail for an asan build (since they won't actually do
> > anything, and if a user runs one they probably would want to
> > know this)? Then we could detect that particular error in the test.
> >
> > (2) We could run the QEMU binary with
> > ASAN_OPTIONS='bang' qemu-system-x86_64 -help >/dev/null 2>&1
> > which will exit success on a non-asan build and fail on an asan
> > build (with an error to stderr about the invalid ASAN_OPTIONS
> > syntax, which we send to /dev/null). Then we could use that to
> > decide whether to skip the test.
> Wouldn't that be possible to simply deactivate this test in meson.build
> in case of sanitized builds?
>
> if get_option('asan')
> ...
Good idea -- that's simple and it works, so let's do that.
I'll send a patch.
-- PMM
