LeakSanitizer no longer usable

[szhorvat (Szabolcs Horvát)]

I am not sure if the following is an issue with Clang in MacPorts or with macOS 13, as I recently changed computers. As I recall, things worked on my previous machine with macOS 13.4 on Intel. However, I may be wrong, as I stayed on 10.14 for a long time and I _may_ not have tested this during the brief period I used 13. The following is tested on macOS 13.5 on Apple Silicon.

LeakSanitizer gives many false positives and is not usable anymore.

Minimal example:

Create the following C file:

// pp.c

int main(void) { return 0; }

Compile and run as:

clang-mp-16 -fsanitize=address pp.c -o pp
ASAN_OPTIONS=detect_leaks=1 ./pp

Output:

pp(72314,0x1e3792080) malloc: nano zone abandoned due to inability to reserve vm space.

=================================================================
==72314==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 72 byte(s) in 1 object(s) allocated from:
    #0 0x10286419c in wrap_malloc+0x88 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x5019c) (BuildId: 7f28487348363def83d523cf4a8af7ae32000000200000000100000000000b00)
    #1 0x188376f58 in _fetchInitializingClassList(bool)+0x2c (libobjc.A.dylib:arm64+0xaf58) (BuildId: ac12887cd6983627b9d1d2e5055a5da432000000200000000100000000050d00)
    #2 0x9b33800188376e2c  (<unknown module>)
    #3 0x361a800188376b34  (<unknown module>)
    #4 0xbe6000018837699c  (<unknown module>)
    #5 0x100d00018837699c  (<unknown module>)
    #6 0xbb5900018837699c  (<unknown module>)
    #7 0x73080001883910e4  (<unknown module>)
    #8 0x9d060001883765c0  (<unknown module>)
    #9 0x921000188375f60  (<unknown module>)
    #10 0x60338001884481f8  (<unknown module>)
    #11 0xba468001884475c0  (<unknown module>)
    #12 0xa2350001940a3678  (<unknown module>)
    #13 0x7d148001883d41d4  (<unknown module>)
    #14 0xe650800188415e90  (<unknown module>)
    #15 0x7c320001884091a0  (<unknown module>)
    #16 0x920f0001883b42d4  (<unknown module>)
    #17 0xeb028001884081c8  (<unknown module>)
    #18 0x84b800188415954  (<unknown module>)
    #19 0x46158001883d0858  (<unknown module>)
    #20 0x486e0001883d9f68  (<unknown module>)
    #21 0x4b680001883f47f8  (<unknown module>)
    #22 0x724c0001883b92cc  (<unknown module>)
    #23 0xb480001883b7e14  (<unknown module>)
    #24 0x592e7ffffffffffc  (<unknown module>)

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x102864544 in wrap_calloc+0x90 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x50544) (BuildId: 7f28487348363def83d523cf4a8af7ae32000000200000000100000000000b00)
    #1 0x18838dc94 in cache_t::insert(objc_selector*, void (*)(), objc_object*)+0x16c (libobjc.A.dylib:arm64+0x21c94) (BuildId: ac12887cd6983627b9d1d2e5055a5da432000000200000000100000000050d00)
    #2 0x721700018837648c  (<unknown module>)
    #3 0xb207800188375f60  (<unknown module>)
    #4 0xa21000018844a82c  (<unknown module>)
    #5 0x60338001884481f8  (<unknown module>)
    #6 0xba468001884475c0  (<unknown module>)
    #7 0xa2350001940a3678  (<unknown module>)
    #8 0x7d148001883d41d4  (<unknown module>)
    #9 0xe650800188415e90  (<unknown module>)
    #10 0x7c320001884091a0  (<unknown module>)
    #11 0x920f0001883b42d4  (<unknown module>)
    #12 0xeb028001884081c8  (<unknown module>)
    #13 0x84b800188415954  (<unknown module>)
    #14 0x46158001883d0858  (<unknown module>)
    #15 0x486e0001883d9f68  (<unknown module>)
    #16 0x4b680001883f47f8  (<unknown module>)
    #17 0x724c0001883b92cc  (<unknown module>)
    #18 0xb480001883b7e14  (<unknown module>)
    #19 0x592e7ffffffffffc  (<unknown module>)

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x102864544 in wrap_calloc+0x90 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x50544) (BuildId: 7f28487348363def83d523cf4a8af7ae32000000200000000100000000000b00)
    #1 0x188376fb4 in _fetchInitializingClassList(bool)+0x88 (libobjc.A.dylib:arm64+0xafb4) (BuildId: ac12887cd6983627b9d1d2e5055a5da432000000200000000100000000050d00)
    #2 0x9b33800188376e2c  (<unknown module>)
    #3 0x361a800188376b34  (<unknown module>)
    #4 0xbe6000018837699c  (<unknown module>)
    #5 0x100d00018837699c  (<unknown module>)
    #6 0xbb5900018837699c  (<unknown module>)
    #7 0x73080001883910e4  (<unknown module>)
    #8 0x9d060001883765c0  (<unknown module>)
    #9 0x921000188375f60  (<unknown module>)
    #10 0x60338001884481f8  (<unknown module>)
    #11 0xba468001884475c0  (<unknown module>)
    #12 0xa2350001940a3678  (<unknown module>)
    #13 0x7d148001883d41d4  (<unknown module>)
    #14 0xe650800188415e90  (<unknown module>)
    #15 0x7c320001884091a0  (<unknown module>)
    #16 0x920f0001883b42d4  (<unknown module>)
    #17 0xeb028001884081c8  (<unknown module>)
    #18 0x84b800188415954  (<unknown module>)
    #19 0x46158001883d0858  (<unknown module>)
    #20 0x486e0001883d9f68  (<unknown module>)
    #21 0x4b680001883f47f8  (<unknown module>)
    #22 0x724c0001883b92cc  (<unknown module>)
    #23 0xb480001883b7e14  (<unknown module>)
    #24 0x592e7ffffffffffc  (<unknown module>)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x102864544 in wrap_calloc+0x90 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x50544) (BuildId: 7f28487348363def83d523cf4a8af7ae32000000200000000100000000000b00)
    #1 0x188376f90 in _fetchInitializingClassList(bool)+0x64 (libobjc.A.dylib:arm64+0xaf90) (BuildId: ac12887cd6983627b9d1d2e5055a5da432000000200000000100000000050d00)
    #2 0x9b33800188376e2c  (<unknown module>)
    #3 0x361a800188376b34  (<unknown module>)
    #4 0xbe6000018837699c  (<unknown module>)
    #5 0x100d00018837699c  (<unknown module>)
    #6 0xbb5900018837699c  (<unknown module>)
    #7 0x73080001883910e4  (<unknown module>)
    #8 0x9d060001883765c0  (<unknown module>)
    #9 0x921000188375f60  (<unknown module>)
    #10 0x60338001884481f8  (<unknown module>)
    #11 0xba468001884475c0  (<unknown module>)
    #12 0xa2350001940a3678  (<unknown module>)
    #13 0x7d148001883d41d4  (<unknown module>)
    #14 0xe650800188415e90  (<unknown module>)
    #15 0x7c320001884091a0  (<unknown module>)
    #16 0x920f0001883b42d4  (<unknown module>)
    #17 0xeb028001884081c8  (<unknown module>)
    #18 0x84b800188415954  (<unknown module>)
    #19 0x46158001883d0858  (<unknown module>)
    #20 0x486e0001883d9f68  (<unknown module>)
    #21 0x4b680001883f47f8  (<unknown module>)
    #22 0x724c0001883b92cc  (<unknown module>)
    #23 0xb480001883b7e14  (<unknown module>)
    #24 0x592e7ffffffffffc  (<unknown module>)

SUMMARY: AddressSanitizer: 152 byte(s) leaked in 4 allocation(s).

I cannot test with GCC, as MacPorts's GCC does not seem to support AddressSanitizer.

$ gcc-mp-12 -fsanitize=address pp.c -o pp
ld: library not found for -lasan
collect2: error: ld returned 1 exit status

If I use clang-mp-15, it show 138 false positives instead of just 4.

If I use clang-mp-14, the executable hangs indefinitely with 100% CPU usage when leak detection is enabled through ASAN_OPTIONS (but not otherwise).

Note that Apple's Clang does not support leak detection.

This trivial example can be fixed by using a "suppressions file" and excluding libobjc.A.dylib.

​https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions

But this approach does not seem to be usable in more complex projects, where mysterious leaks are reported from "unknown" locations that I cannot include in a suppressions file.

Overall, it seems to me that there may be something wrong with leaks detection in MacPorts's Clang.

Any comments on this, as well as on whether the issue is specific to my machine, would be much appreciated.

[cjones051073 (Chris Jones)]

You say this is an issue with 'macport clang' but from your report above I cannot conclude it isn't just an issue in LLVM per se with the sanitizers on Apple Silicon.

I suggest you start by taking this upstream, to LLVM, to see what they say. Only then can we conclude if its unique to Macports clang builds, or just a more general upstream issue.

[szhorvat (Szabolcs Horvát)]

Would you be able to help in figuring out what platforms / OS versions are affected? At the moment I cannot test on any other macOS versions. All I am certain about is that macOS 10.14 on Intel wasn't affected a few months ago, but I'm not even sure if MacPort's Clang changed since then.

[cjones051073 (Chris Jones)]

Me personally no, I cannot. My last Intel machine died a month back so now I only have access to macOS13 arm64. My VMs for old OSes cannot be run any longer as its not possible to virtualise x86_64 on arm machines.

[szhorvat (Szabolcs Horvát)]

Could you please confirm that you see the same on your macOS 13 arm64 system, just to make sure something's not broken on mine specifically?

[cjones051073 (Chris Jones)]

I indeed see the same as you above.

I suggest you maybe ask on the devel mailing list to if there are any kind souls there able to help you out.

[szhorvat (Szabolcs Horvát)]

For reference, here's my post on the LLVM Discourse forum, which replaces the mailing list. No response so far, even though macOS on arm64 is stated as a supported platform.

​https://discourse.llvm.org/t/does-leaksanitizer-not-work-on-macos-13-apple-silicon/73148/

I realize that Apple Clang 14 now does include LSan support, and it also does not work, which demonstrates that this is not a MacPorts issue. Feel free to close this.