Intermittent free-without-malloc in heavily threaded safe code on ARM64 Mac

This is, I appreciate, the most irritating kind of bug; sometimes, not always, after between ten minutes and a few hours of running, I get a message of the form

discrete(26320,0x16f4ab000) malloc: *** error for object 0x6000017981c0: pointer being freed was not allocated
discrete(26320,0x16f4ab000) malloc: *** set a breakpoint in malloc_error_break to debug

where the two addresses are not constant - another failure was

discrete(24106,0x16bf4f000) malloc: *** error for object 0x600001e48080: pointer being freed was not allocated
discrete(24106,0x16bf4f000) malloc: *** set a breakpoint in malloc_error_break to debug

when running the following short piece of code without unsafe operations built in release mode with rustc-1.75.0 on my M1 Mac under OS X 14.1.2

I have not seen the same issue running the same source, built with the same rustc, on an x86-64 machine with rather more threads under ubuntu-20.04; I have run it for considerably longer on that machine. The code does do a lot of small malloc/free operations, they're about 30% of the cycle count when I run it under perf on linux.

cargo audit doesn't mention any advisories.

What do I do next, beyond 'just run the long jobs on the Linux box'? Is there some combination of environment variables and debugger options that it would be helpful to set before running the thing on repeat on the Mac and waiting for another crash?

1 Like

You'll probably get more eyes on your "short" code if you include it in a code block in your post instead of only providing a link.


Since you're debugging allocations the Valgrind would be the natural step you can try next.

You could also try to swap the allocator.

Unfortunately Valgrind doesn't exist on Mac OS and the problem doesn't occur under Linux

Do you have a way to confirm if this occurs on a non-ARM Mac? If it doesn't then my guess would be a data race due to wrong atomic ordering in either the allocator or rayon/crossbeam.