1568070 - LeakSanitizer: Multiple leaks [@ vixl::CachingDecoder] or [@ vixl::Redirection] with ARM64 simulator

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect, P3)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: leaks.txt

The following testcase crashes on mozilla-central revision c05f61052576 (build with --enable-debug --enable-simulator=arm64 --enable-address-sanitizer, run with --fuzzing-safe and the environment variables ASAN_OPTIONS=detect_leaks=1 LSAN_OPTIONS=max_leaks=20):

quit();

Backtrace:

The 20 top leak(s):
Direct leak of 176 byte(s) in 1 object(s) allocated from:
    #0 0x55ebf6c5f9d3 in __interceptor_malloc /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146:3
    #1 0x55ebf922c5ae in js_arena_malloc(unsigned long, unsigned long) /home/fuzz3/shell-cache/js-dbg-64-asan-armsim64-linux-x86_64-c05f61052576/objdir-js/dist/include/js/Utility.h:392:10
    #2 0x55ebf922c5ae in js_malloc(unsigned long) /home/fuzz3/shell-cache/js-dbg-64-asan-armsim64-linux-x86_64-c05f61052576/objdir-js/dist/include/js/Utility.h:396
    #3 0x55ebf922c5ae in vixl::CachingDecoder* js_new<vixl::CachingDecoder>() /home/fuzz3/shell-cache/js-dbg-64-asan-armsim64-linux-x86_64-c05f61052576/objdir-js/dist/include/js/Utility.h:545
    #4 0x55ebf922c5ae in vixl::Simulator::Create() /home/fuzz3/trees/mozilla-central/js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:171
    #5 0x55ebf74ae52b in JSContext::init(js::ContextKind) /home/fuzz3/trees/mozilla-central/js/src/vm/JSContext.cpp:117:18
/snip

For detailed crash information, see attachment.

Setting needinfo? from our ARM64 folks here. Nicolas/Sean, what's next?

Comment 1

[Nicolas B. Pierron [:nbp]]

This is expected, and my understanding is that other simulators do the same thing.
I suggest adding this to the ignored signature, if possible.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Which line should be suppressed? Or anything containing vixl?

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)

Which line should be suppressed? Or anything containing vixl?

This is the function I will suggest to suppress:
vixl::CachingDecoder* js_new<vixl::CachingDecoder>()

Comment 4

[Sean Stangl [:sstangl]]

The vixl::Decoder indeed does not safely clean up after itself in general. Simulator::Destroy() was removed by upstream. The Simulator in general is expected to live for the lifetime of the process and therefore doesn't clean up memory.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Sean Stangl [:sstangl] from comment #4)

The vixl::Decoder indeed does not safely clean up after itself in general. Simulator::Destroy() was removed by upstream. The Simulator in general is expected to live for the lifetime of the process and therefore doesn't clean up memory.

If this is the case, is there value in running LSan for the simulator? i.e. will LSan be able to find ARM64 leaks on the ARM64 simulator on x86_64 (assuming we ignore every stack containing vixl::CachingDecoder / vixl::Simulator), or shall we leave that to the native ARM64 binary instead?

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #5)

If this is the case, is there value in running LSan for the simulator? i.e. will LSan be able to find ARM64 leaks on the ARM64 simulator on x86_64 (assuming we ignore every stack containing vixl::CachingDecoder / vixl::Simulator), or shall we leave that to the native ARM64 binary instead?

I do not see much value in running any LSan ARM64 on the simulator. Most allocations are handled the same way across platforms, except for the Assembly buffer, and this code is not expected to change in the next 6 months, as far as I know.

Comment 7

[Sean Stangl [:sstangl]]

I assume you would be able to find ARM64 leaks with the Simulator if you ignored vixl::CachingDecoder / vixl::Simulator (and possibly other related things). So it probably is valuable to test -- at least, relative to a native binary, which is likely to be prohibitively slow. That's pretty much the whole justification for the Simulator's existence. Otherwise, we could tell people to just run binaries through qemu!

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Sean Stangl [:sstangl] from comment #7)

which is likely to be prohibitively slow. That's pretty much the whole justification for the Simulator's existence.

We now test on A1 ARM64 instances on EC2, so the speed issue is way less of a problem now. See https://aws.amazon.com/blogs/aws/new-ec2-instances-a1-powered-by-arm-based-aws-graviton-processors/

I've now disabled testing LSan on ARM64 simulators instead. Resolving INVALID. Thanks Nicolas and Sean!