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.
Questions:
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?
1 Like
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:
https://releases.llvm.org/16.0.0/tools/clang/docs/LeakSanitizer.html#supported-platforms
I notice that there was already a similar report on GitHub, but it did not receive much attention:
opened 02:49AM - 22 Mar 22 UTC
I am running on `Mac M1` with `clang version 13.0.1`.
When I run the leak san… itizer for example code shown in the [Clang 13 documentation](https://releases.llvm.org/13.0.0/tools/clang/docs/index.html),
```c
$ cat memory-leak.c
#include <stdlib.h>
void *p;
int main() {
p = malloc(7);
p = 0; // The memory is leaked here.
return 0;
}
$ clang -fsanitize=address -g memory-leak.c ; ASAN_OPTIONS=detect_leaks=1 ./a.out
```
the output shows that "4071 byte(s) leaked in 128 allocation(s)", with many of the leaked bytes coming from objects in the `<unknown module>`.
I also tested it against the code shown below:
```c
$ cat memory-leak.c
int main()
{
return 0;
}
$ clang -fsanitize=address -g memory-leak.c ; ASAN_OPTIONS=detect_leaks=1 ./a.out
```
It shows that "4064 byte(s) leaked in 127 allocation(s)".
It appears that by default, there are 4064 bytes leaked. The complete output of the second program is shown below.
```
==72058==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1856 byte(s) in 58 object(s) allocated from:
#0 0x1030c7a2c in wrap_calloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3fa2c)
#1 0x19a4be484 in realizeClassWithoutSwift(objc_class*, objc_class*)+0x8c (libobjc.A.dylib:arm64+0x5484)
#2 0x315b00019a4be608 (<unknown module>)
#3 0x7c1280019a4bc61c (<unknown module>)
#4 0x7a3000019a4baf40 (<unknown module>)
#5 0xf74c000102ce7948 (<unknown module>)
#6 0x311e800102ce2988 (<unknown module>)
#7 0x749800102ce780c (<unknown module>)
#8 0xb511000102cfc800 (<unknown module>)
#9 0x3c5580019a4bae04 (<unknown module>)
#10 0x301b00019a4754e0 (<unknown module>)
#11 0xe4880019a484cbc (<unknown module>)
#12 0x6e148001a51806a4 (<unknown module>)
#13 0xa842800102cedd8c (<unknown module>)
#14 0x732800102d1717c (<unknown module>)
#15 0x194c800102d0dbc8 (<unknown module>)
#16 0x9221800102cd9f94 (<unknown module>)
#17 0x2d1d000102d0d970 (<unknown module>)
#18 0x307a000102d16bcc (<unknown module>)
#19 0x957f800102cedccc (<unknown module>)
#20 0x5f22000102cf47c8 (<unknown module>)
#21 0x1325800102d02fe8 (<unknown module>)
#22 0x431b800102cdddb4 (<unknown module>)
#23 0xfc30000102cdd064 (<unknown module>)
#24 0x4737ffffffffffc (<unknown module>)
Direct leak of 1856 byte(s) in 58 object(s) allocated from:
#0 0x1030c7a2c in wrap_calloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3fa2c)
#1 0x19a4be484 in realizeClassWithoutSwift(objc_class*, objc_class*)+0x8c (libobjc.A.dylib:arm64+0x5484)
#2 0x7c1280019a4bc61c (<unknown module>)
#3 0x7a3000019a4baf40 (<unknown module>)
#4 0xf74c000102ce7948 (<unknown module>)
#5 0x311e800102ce2988 (<unknown module>)
#6 0x749800102ce780c (<unknown module>)
#7 0xb511000102cfc800 (<unknown module>)
#8 0x3c5580019a4bae04 (<unknown module>)
#9 0x301b00019a4754e0 (<unknown module>)
#10 0xe4880019a484cbc (<unknown module>)
#11 0x6e148001a51806a4 (<unknown module>)
#12 0xa842800102cedd8c (<unknown module>)
#13 0x732800102d1717c (<unknown module>)
#14 0x194c800102d0dbc8 (<unknown module>)
#15 0x9221800102cd9f94 (<unknown module>)
#16 0x2d1d000102d0d970 (<unknown module>)
#17 0x307a000102d16bcc (<unknown module>)
#18 0x957f800102cedccc (<unknown module>)
#19 0x5f22000102cf47c8 (<unknown module>)
#20 0x1325800102d02fe8 (<unknown module>)
#21 0x431b800102cdddb4 (<unknown module>)
#22 0xfc30000102cdd064 (<unknown module>)
#23 0x4737ffffffffffc (<unknown module>)
Direct leak of 160 byte(s) in 5 object(s) allocated from:
#0 0x1030c7a2c in wrap_calloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3fa2c)
#1 0x19a4be484 in realizeClassWithoutSwift(objc_class*, objc_class*)+0x8c (libobjc.A.dylib:arm64+0x5484)
#2 0xa15f80019a4be5f0 (<unknown module>)
#3 0x7c1280019a4bc61c (<unknown module>)
#4 0x7a3000019a4baf40 (<unknown module>)
#5 0xf74c000102ce7948 (<unknown module>)
#6 0x311e800102ce2988 (<unknown module>)
#7 0x749800102ce780c (<unknown module>)
#8 0xb511000102cfc800 (<unknown module>)
#9 0x3c5580019a4bae04 (<unknown module>)
#10 0x301b00019a4754e0 (<unknown module>)
#11 0xe4880019a484cbc (<unknown module>)
#12 0x6e148001a51806a4 (<unknown module>)
#13 0xa842800102cedd8c (<unknown module>)
#14 0x732800102d1717c (<unknown module>)
#15 0x194c800102d0dbc8 (<unknown module>)
#16 0x9221800102cd9f94 (<unknown module>)
#17 0x2d1d000102d0d970 (<unknown module>)
#18 0x307a000102d16bcc (<unknown module>)
#19 0x957f800102cedccc (<unknown module>)
#20 0x5f22000102cf47c8 (<unknown module>)
#21 0x1325800102d02fe8 (<unknown module>)
#22 0x431b800102cdddb4 (<unknown module>)
#23 0xfc30000102cdd064 (<unknown module>)
#24 0x4737ffffffffffc (<unknown module>)
Direct leak of 128 byte(s) in 4 object(s) allocated from:
#0 0x1030c7a2c in wrap_calloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3fa2c)
#1 0x19a4be484 in realizeClassWithoutSwift(objc_class*, objc_class*)+0x8c (libobjc.A.dylib:arm64+0x5484)
#2 0x566380019a4be608 (<unknown module>)
#3 0xa15f80019a4be5f0 (<unknown module>)
#4 0x7c1280019a4bc61c (<unknown module>)
#5 0x7a3000019a4baf40 (<unknown module>)
#6 0xf74c000102ce7948 (<unknown module>)
#7 0x311e800102ce2988 (<unknown module>)
#8 0x749800102ce780c (<unknown module>)
#9 0xb511000102cfc800 (<unknown module>)
#10 0x3c5580019a4bae04 (<unknown module>)
#11 0x301b00019a4754e0 (<unknown module>)
#12 0xe4880019a484cbc (<unknown module>)
#13 0x6e148001a51806a4 (<unknown module>)
#14 0xa842800102cedd8c (<unknown module>)
#15 0x732800102d1717c (<unknown module>)
#16 0x194c800102d0dbc8 (<unknown module>)
#17 0x9221800102cd9f94 (<unknown module>)
#18 0x2d1d000102d0d970 (<unknown module>)
#19 0x307a000102d16bcc (<unknown module>)
#20 0x957f800102cedccc (<unknown module>)
#21 0x5f22000102cf47c8 (<unknown module>)
#22 0x1325800102d02fe8 (<unknown module>)
#23 0x431b800102cdddb4 (<unknown module>)
#24 0xfc30000102cdd064 (<unknown module>)
#25 0x4737ffffffffffc (<unknown module>)
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x1030c7a2c in wrap_calloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3fa2c)
#1 0x19a4be484 in realizeClassWithoutSwift(objc_class*, objc_class*)+0x8c (libobjc.A.dylib:arm64+0x5484)
#2 0xaa7f80019a4be5f0 (<unknown module>)
#3 0xa15f80019a4be5f0 (<unknown module>)
#4 0x7c1280019a4bc61c (<unknown module>)
#5 0x7a3000019a4baf40 (<unknown module>)
#6 0xf74c000102ce7948 (<unknown module>)
#7 0x311e800102ce2988 (<unknown module>)
#8 0x749800102ce780c (<unknown module>)
#9 0xb511000102cfc800 (<unknown module>)
#10 0x3c5580019a4bae04 (<unknown module>)
#11 0x301b00019a4754e0 (<unknown module>)
#12 0xe4880019a484cbc (<unknown module>)
#13 0x6e148001a51806a4 (<unknown module>)
#14 0xa842800102cedd8c (<unknown module>)
#15 0x732800102d1717c (<unknown module>)
#16 0x194c800102d0dbc8 (<unknown module>)
#17 0x9221800102cd9f94 (<unknown module>)
#18 0x2d1d000102d0d970 (<unknown module>)
#19 0x307a000102d16bcc (<unknown module>)
#20 0x957f800102cedccc (<unknown module>)
#21 0x5f22000102cf47c8 (<unknown module>)
#22 0x1325800102d02fe8 (<unknown module>)
#23 0x431b800102cdddb4 (<unknown module>)
#24 0xfc30000102cdd064 (<unknown module>)
#25 0x4737ffffffffffc (<unknown module>)
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x1030c7a2c in wrap_calloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x3fa2c)
#1 0x19a4be484 in realizeClassWithoutSwift(objc_class*, objc_class*)+0x8c (libobjc.A.dylib:arm64+0x5484)
#2 0xfa5b00019a4be608 (<unknown module>)
#3 0xaa7f80019a4be5f0 (<unknown module>)
#4 0xa15f80019a4be5f0 (<unknown module>)
#5 0x7c1280019a4bc61c (<unknown module>)
#6 0x7a3000019a4baf40 (<unknown module>)
#7 0xf74c000102ce7948 (<unknown module>)
#8 0x311e800102ce2988 (<unknown module>)
#9 0x749800102ce780c (<unknown module>)
#10 0xb511000102cfc800 (<unknown module>)
#11 0x3c5580019a4bae04 (<unknown module>)
#12 0x301b00019a4754e0 (<unknown module>)
#13 0xe4880019a484cbc (<unknown module>)
#14 0x6e148001a51806a4 (<unknown module>)
#15 0xa842800102cedd8c (<unknown module>)
#16 0x732800102d1717c (<unknown module>)
#17 0x194c800102d0dbc8 (<unknown module>)
#18 0x9221800102cd9f94 (<unknown module>)
#19 0x2d1d000102d0d970 (<unknown module>)
#20 0x307a000102d16bcc (<unknown module>)
#21 0x957f800102cedccc (<unknown module>)
#22 0x5f22000102cf47c8 (<unknown module>)
#23 0x1325800102d02fe8 (<unknown module>)
#24 0x431b800102cdddb4 (<unknown module>)
#25 0xfc30000102cdd064 (<unknown module>)
#26 0x4737ffffffffffc (<unknown module>)
SUMMARY: AddressSanitizer: 4064 byte(s) leaked in 127 allocation(s).
```
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.
1 Like
Same result with LLVM / Clang 17.0.1.
this problem is indeed boring！many times I don’t known why these builtin library functions are considered leak , especially when including them in the suppression file might result in overlooking the real leak.
I posted a question on StackOverflow for the same problem three months ago. Unfortunately, it appears that there is still no one who can provide a precise yes/no answer. I have also tested it on Clang 18, but the problem continues to persist.
The problem is still there with Clang 20.1.1.
It would be good to get some statement from the developers about whether Apple Silicon is supported at all.
fmayer
August 20, 2025, 10:11pm
7
Maybe @fhahn who has been working on sanitizers for macOS can give some answer