Valgrind crashes macOS 15 on arm64

[LouisBrunner]

As discussed https://github.com/LouisBrunner/valgrind-macos/issues/56#issuecomment-2442886835, Valgrind suffers from some kind of memory issues on arm64, causing the whole system to slow down and/or crash.

Click here if you want to use Valgrind on arm64 right now, even though it might crash or even damage your computer

Because of the above reason, arm64 support is hidden behind an opt-in environment variable. Make sure you are aware of the risk of using such an experimental version of Valgrind. As stated in the Valgrind license (which applies to this fork as well), we accept no liability for any damage (be it a loss of data, damage to your computer, loss of warranty or anything else) resulting from your use of Valgrind.

Click here to acknowledge you are aware of the risks and accept that the maintainers of Valgrind and this fork are not liable for any damage to your computer

If you want to use Valgrind on arm64, you will need to set the environment variable I_ACKNOWLEDGE_THIS_MIGHT_CRASH_OR_DAMAGE_MY_COMPUTER to a value of yes.

Note: when building with brew, you will need to use HOMEBREW_I_ACKNOWLEDGE_THIS_MIGHT_CRASH_OR_DAMAGE_MY_COMPUTER=yes while running brew install or brew upgrade.

This needs to be done while building (during ./configure to be exact) and while running Valgrind itself.

This issue is dedicated to discussion and resolution of this specific memory issue and not to general arm64 support or related issues (e.g. suppressions). If you want to report other issues with arm64, please create a new issue. Any off-topic comments will be mark as such and hidden.

Once this issue is resolved, the opt-in will be removed and arm64 will be available without extra flag.

[LouisBrunner]

Adding @paulfloyd info from #136 here.

I came across this discussion on Reddit:

https://www.reddit.com/r/rust/comments/1lg12fm/trying_to_profiling_heap_on_macos_is_frustrating/

Hope it is of use.

[LouisBrunner]

I am wondering if only macOS 15 (or M1 Macs) should be forbidden to build without the env var. I don't have access to a non-M1 arm64 Mac but I could try earlier versions using VMs. It wouldn't give me ton of confidence though.

However, if people are ready to run the regression test suite on their computer (any Mac with macOS 11 to 14 or any macOS with a non-M1 Mac), I could be convinced to remove the env var for specific configurations.

[real-or-random]

I am wondering if only macOS 15 (or M1 Macs) should be forbidden to build without the env var. I don't have access to a non-M1 arm64 Mac but I could try earlier versions using VMs. It wouldn't give me ton of confidence though.

However, if people are ready to run the regression test suite on their computer (any Mac with macOS 11 to 14 or any macOS with a non-M1 Mac), I could be convinced to remove the env var for specific configurations.

Would you be open to allowing macOS 14 if running on GitHub Actions (e.g., if the GITHUB_ACTIONS env variable is set)? This combination seems to work in your CI. This would save us from the need to fiddle with the build or the homebrew file.

[LouisBrunner]

Would you be open to allowing macOS 14 if running on GitHub Actions (e.g., if the GITHUB_ACTIONS env variable is set)? This combination seems to work in your CI.

I would like to avoid further env var magic if possible. If I had access to an arm64 macOS 14 computer I would just run Valgrind against Firefox and I could check for sure that it's safe. While the issue shows for macOS 15 in the CI, I am worried that the issue might also be there for earlier versions but might just need more usage to be triggered.

This would save us from the need to fiddle with the build or the homebrew file.

Isn't defining the env var in your YAML file enough?

[real-or-random]

This would save us from the need to fiddle with the build or the homebrew file.

Isn't defining the env var in your YAML file enough?

I think you're right, and I just misremembered. I checked a long time ago and couldn't see a way to make arm64 work with brew easily. But now that I think about it, the issue was that it's impossible to tell brew to build a specific branch or commit (except HEAD). So this was before the arm64 support was merged into main. Now after the merge, setting the env var should be enough.

Nevermind.

[real-or-random]

Oh, I now see what the problem is. The formula will just refuse to build on arm: https://github.com/LouisBrunner/homebrew-valgrind/blob/17a8942b020ffb91cb8b9e5ab98a9630c04d981b/valgrind.rb#L20-L22

[LouisBrunner]

Just merged an updated formula, sorry about that! 😄 Note that you will need to use HOMEBREW_I_ACKNOWLEDGE_THIS_MIGHT_CRASH_OR_DAMAGE_MY_COMPUTER during the brew install and the other name when running, sorry about the extra annoyance.

By the way, I just noticed something interesting: https://github.com/LouisBrunner/valgrind-macos/actions/runs/18512224339/job/52755435120 It seems like builds on macOS 15 both amd64 and arm64 are failing. So maybe the issue is a fundamental flaw of macOS 15 itself instead of arm64?

I am going to keep thinking on it but I think I will change the env var to disable macOS 15 for both architectures instead and let earlier arm64 version build as normal. This issue would be rephrased to reflect that as well.

[real-or-random]

Just merged an updated formula, sorry about that! 😄

Thanks!

By the way, I just noticed something interesting: [LouisBrunner/valgrind-macos/actions/runs/18512224339/job/52755435120] (https://github.com/LouisBrunner/valgrind-macos/actions/runs/18512224339/job/52755435120) It seems like builds on macOS 15 both amd64 and arm64 are failing. So maybe the issue is a fundamental flaw of macOS 15 itself instead of arm64?

This matches what we see. But it's also GitHub Actions, so it's not a very interesting data point. https://github.com/bitcoin-core/secp256k1/pull/1755#issuecomment-3406663186

[prldev]

I have a Mac on macos 14 and a M3 processor which I'm ready to use for some tests. But installation fail at link stage with following error:

/usr/bin/ld -Z -L../coregrind -lmySystem -lmydyld -segaddr __TEXT 0x158000000 -headerpad 256 -new_linker -arch arm64 -macos_version_min 11.0 -o memcheck-arm64-darwin -u __start -e __start -stack_size 0x800000 memcheck_arm64_darwin-mc_leakcheck.o memcheck_arm64_darwin-mc_malloc_wrappers.o memcheck_arm64_darwin-mc_main.o memcheck_arm64_darwin-mc_main_asm.o memcheck_arm64_darwin-mc_translate.o memcheck_arm64_darwin-mc_machine.o memcheck_arm64_darwin-mc_errors.o ../coregrind/libcoregrind-arm64-darwin.a ../VEX/libvex-arm64-darwin.a 
ld: warning: -new_linker is obsolete
0  0x104eb447c  __assert_rtn + 72
1  0x104e11778  ld::OpcodeFixupsEncoder::writeFixupsLinkEditContent(std::__1::span<unsigned char, 18446744073709551615ul>) + 1048
2  0x104e60c04  ld::LayoutExecutable::writeToFile(char const*) + 8272
3  0x104e735d4  ld::Linker::run() + 8424
4  0x104dff768  main + 1556
ld: Assertion failed: (((Header*)(fileOutputBuffer))->hasMachOMagic()), function writeFixupsLinkEditContent, file Layout.cpp, line 809.

I have no idea where the issue is, I checked all files used during this link step and all seems to be fine.

[LouisBrunner]

@prldev Can you open a new issue? Also include your version of Xcode, ld, etc.

[LouisBrunner]

With the addition of macOS 26 Tahoe support (#152), I have done a few changes.

Given than macOS 26 runs fine (but very slow, nearly 3x slower than on macOS 14), I have decided that the crash is specific to macOS 15 and thus I have removed the env var requirement for all Valgrind versions but macOS 15 arm64. Similarly, I have removed macOS 15 from the platforms tested in the CI of this repo too.

Given that I don't see this issue on my macOS 15 amd64 computer, I imagine that the macos-15-intel runner might be virtualized on arm64 and thus hit the same fault as the macos-15 ones. So macOS 15 amd64 stays accessible without env var as well.

[LouisBrunner]

Just adding another anecdotal data point here, in case it happens to anyone else.

I was doing some testing yesterday on my machine (macOS 15) and ended up crashing it (which happens semi-regularly). However, after forcing a reboot, I couldn't login any more. I spent a good 2h to try to find the root cause before I discovered that one of the folders in /private/var/folders had the max amount of hardlinks (65535) and close to 108MB of disk usage (for the folder itself, not the content). macOS would hang forever if I tried to do anything with it (delete, look inside, etc) apart from moving it around. After doing just that, the computer booted again. I still have the file on my disk.

While it's possible that macOS 15 crashing and this weird file corruption might be unrelated (and maybe a hardware fault of my disk), it is worth keeping in mind just in case it happens to anyone else. It might make sense that the whole system comes to a halt as the affected directory seems to be the one emulating /tmp.