AddressSanitizer broken in macOS 26.4

# AddressSanitizer broken in macOS 26.4 A debugging tool that many systems programmers rely on now has a new failure mode on Apple’s latest operating system: it can simply hang. In Apple’s release notes for macOS Tahoe 26.4 and Xcode 26.4, the company says Address Sanitizer and Thread Sanitizer “might hang” on macOS 26.4 and the other 26.4 platform releases when code was built with Xcode 26.3 or older, and the official workaround is to use Xcode 26.4 for testing. (developer.apple.com) Address Sanitizer is one of the standard bug-finding tools for C and C++ code. It works by adding extra checks during compilation and linking in a runtime library so the program can catch mistakes like writing past the end of an array, using freed memory, or double-freeing an allocation while the program runs. (github.com) That matters most for low-level code, where memory bugs often hide far away from the point where they finally crash something. Address Sanitizer is popular because it usually turns vague corruption into a direct report with a stack trace, and the Clang documentation says the typical slowdown is about 2x, which is slow enough to notice but fast enough to use in regular testing. (clang.llvm.org) Apple’s note does not describe the issue as a random regression in one app. It describes a compatibility break tied to the combination of operating system version and build tool version: macOS 26.4 and related 26.4 platform releases on one side, and binaries built with Xcode 26.3 or older on the other. (developer.apple.com) That distinction is why developers are calling this more than a routine bug. If the operating system update changes sanitizer behavior in a way that requires a newer Apple toolchain, teams that build outside Xcode can lose a debugging workflow they already had, even if their code itself did not change. Apple’s published workaround is not “rebuild with any newer Clang,” but specifically “Use Xcode 26.4 when testing applications with Address Sanitizer or Thread Sanitizer.” (developer.apple.com) For teams shipping ordinary Mac apps, that may be annoying but manageable. For teams maintaining cross-platform runtimes, databases, networking stacks, language toolchains, storage engines, or other systems software, it is a bigger disruption because sanitizer runs are often wired into build systems that are meant to behave the same way across Linux, Windows, and macOS. (clang.llvm.org) Address Sanitizer is not just an Xcode feature. The LLVM documentation describes it as part of the Clang and compiler-rt toolchain, enabled with the `-fsanitize=address` flag, which is why developers expect it to behave like a compiler-and-runtime capability rather than an integrated-development-environment-only switch. (clang.llvm.org) That expectation is what makes Apple’s workaround feel narrow. If the practical fix is “move your testing onto Xcode 26.4,” then a workflow built around custom Clang builds, CMake, Bazel, Rust, mixed-language toolchains, or remote reproducible builds becomes harder to keep aligned across machines and operating systems. This is an inference from Apple’s workaround and from how Address Sanitizer is normally used in LLVM-based toolchains. (developer.apple.com) The release notes also say the same hang can affect Thread Sanitizer, which is the tool used to catch data races in multithreaded code. That broadens the impact from memory corruption testing to concurrency debugging, two of the hardest classes of bugs in systems programming. (developer.apple.com) The practical pain is not usually production deployment. Most server software is not shipped with sanitizers turned on because of the runtime overhead and because these tools are mainly for test builds. The pain lands earlier, during debugging, continuous integration, and pre-release investigation, where a hang in the sanitizer can stall a test job without producing the crash report the developer was trying to get. (clang.llvm.org) Apple has at least documented the problem clearly enough that affected developers can identify the trigger: macOS 26.4-era systems plus binaries built with Xcode 26.3 or older. But the documentation available today does not explain why the hang happens internally, whether the change was intentional in a technical sense, or whether Apple plans to restore compatibility for older toolchains in a later update. (developer.apple.com) So the story here is not that macOS 26.4 makes software unsafe to ship. The story is that one of the main instruments developers use to find unsafe memory behavior now appears tied more tightly to Apple’s newest toolchain, and that shifts debugging work toward Xcode at the exact layer of software development where teams usually want the most portability and control. (developer.apple.com)