skipping the x86_64/test_memlock.py functional test when QEMU built with asan

skipping the x86_64/test_memlock.py functional test when QEMU built with asan

[Peter Maydell]

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.

thanks
-- PMM

Re: skipping the x86_64/test_memlock.py functional test when QEMU built with asan

[Pierrick Bouvier]

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.
> 
> thanks
> -- PMM
> 

Wouldn't that be possible to simply deactivate this test in meson.build 
in case of sanitized builds?

if get_option('asan')
...
endif

Re: skipping the x86_64/test_memlock.py functional test when QEMU built with asan

[Peter Maydell]

On Sun, 8 Mar 2026 at 23:39, Pierrick Bouvier
<pierrick.bouvier@linaro.org> 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