Does LeakSanitizer not work on macOS 13 / Apple Silicon?

LeakSanitizer does not seem to work correctly on macOS 13.5 on Apple Silicon, and I’m wondering what changed, since I’ve been using this feature successfully on earlier macOS / Intel.

I am using open-source Clang from MacPorts, and I see the following behaviour. There are leaks reported even for a barebones C program int main(void) { return 0; }, compiled using clang -fsanitize=address -g -fno-omit-frame-pointer, and run with ASAN_OPTIONS=detect_leaks=1.

With clang version 16.0.6, I get 4 leaks reported. With clang version 15.0.7, I see 138 leak reports. With clang version 14.0.6, the program hangs indefinitely with 100% CPU usage when leak detection is enabled.

Leak reports look similar to the following, but I was not able to deal with them using a suppressions file in a real project, since they don’t always come from an identifiable place (libobjc.A.dylib is mentioned here, but sometimes it’s only <unknown module>)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x104759ec4 in wrap_calloc+0x90 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3dec4) (BuildId: b100a6c8bcc13b048edb87902f84fa7832000000200000000100000000000b00)
    #1 0x1a8592f90 in _fetchInitializingClassList(bool)+0x64 (libobjc.A.dylib:arm64+0xaf90) (BuildId: ac12887cd6983627b9d1d2e5055a5da432000000200000000100000000050d00)
    #2 0x110f0001a8592e2c  (<unknown module>)
    #3 0x5c3d8001a8592b34  (<unknown module>)
    #4 0xe4670001a859299c  (<unknown module>)
    #5 0x400f0001a859299c  (<unknown module>)
    #6 0x795a8001a859299c  (<unknown module>)
    #7 0x59288001a85ad0e4  (<unknown module>)
    #8 0x6b790001a85925c0  (<unknown module>)
    #9 0x55d0001a8591f60  (<unknown module>)
    #10 0x297c8001a86641f8  (<unknown module>)
    #11 0xab0b0001a86635c0  (<unknown module>)
    #12 0xe4028001b42bf678  (<unknown module>)
    #13 0x410a0001a85f01d4  (<unknown module>)
    #14 0xe1440001a8631e90  (<unknown module>)
    #15 0x98578001a86251a0  (<unknown module>)
    #16 0xbc658001a85d02d4  (<unknown module>)
    #17 0x18038001a86241c8  (<unknown module>)
    #18 0x5c3c0001a8631954  (<unknown module>)
    #19 0x5a140001a85ec858  (<unknown module>)
    #20 0xe7c8001a85f5f68  (<unknown module>)
    #21 0x40338001a86107f8  (<unknown module>)
    #22 0xa720001a85d52cc  (<unknown module>)
    #23 0xfd1d8001a85d3e14  (<unknown module>)
    #24 0x5320fffffffffffc  (<unknown module>)

All these Clang versions worked fine on macOS 10.14.6 with an Intel processor.

As I recall, they also worked fine on macOS 13 / Intel, but I am not certain.


Is LeakSanitizer expected to work on this platform? Is the problem I see specific to Apple Silicon? Could something be wrong with MacPorts’s Clang builds (issue report)?

Most importantly, is there a practical workaround?

I assumed that this platform may not be supported, but it is in fact stated as a supported platform for LLVM 16.0 in the documentation:

I notice that there was already a similar report on GitHub, but it did not receive much attention:

Let me also include an example which demonstrates that this issue can’t be worked around with suppression files:

Direct leak of 6964 byte(s) in 1 object(s) allocated from:
    #0 0x102fc019c in wrap_malloc+0x88 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x5019c) (BuildId: 7f28487348363def83d523cf4a8af7ae32000000200000000100000000000b00)
    #1 0x1a85e1fe0  (<unknown module>)
    #2 0x211d8001a8933ec8  (<unknown module>)
    #3 0x677600010400b3a8  (<unknown module>)
    #4 0x102b3fd54 in main dqueue.c:112
    #5 0x1a85d3f24  (<unknown module>)
    #6 0x49447ffffffffffc  (<unknown module>)

Suppressions used:
  count      bytes template
      4        152 libobjc.A.dylib
      3        148 libsystem_c.dylib

SUMMARY: AddressSanitizer: 6964 byte(s) leaked in 1 allocation(s).

This comes from one of the simpler tests in the igraph library, when the library is compiled without any external dependencies.

Same result with LLVM / Clang 17.0.1.