google/sanitizers: the archived home of AddressSanitizer, ThreadSanitizer and MemorySanitizer

What google/sanitizers was for, and who it was for

The repository collects the documentation and helper code for a family of compiler-based bug detectors: AddressSanitizer, which the README describes as detecting addressability issues, LeakSanitizer for memory leaks, ThreadSanitizer for data races and deadlocks, MemorySanitizer for use of uninitialized memory, plus HWASAN and UBSan. The audience was never application developers looking for a library to link against. It was compiler engineers, runtime maintainers and the people porting these tools to new platforms, which is why the top level of the repository holds directories such as android/, buildbot/ and dashboard/ rather than a build system for end users.

The README opens with an archived notice, and that changes the answer to the obvious question. If you arrived here because you want to find memory bugs in your own program, this repository is not the thing you install. The sanitizers ship inside the compiler toolchain you already have, and the README states that the core code for these sanitizers resides within the LLVM repository. What remains here is historical documentation, bugfixes and helper code, retained for archival purposes.

How the sanitizers work: instrumentation, shadow memory, runtime

The mechanism is the same across the family, and it is a compiler transformation rather than a library you call. When you pass a sanitizer flag, the compiler inserts checks around memory accesses, and a runtime library that ships with the toolchain handles the reporting. For AddressSanitizer, the README points to a wiki page covering addressability issues, and the design notes referenced for HWASAN describe the same shadow-memory idea with a smaller memory footprint, which is the trade-off that makes HWASAN usable on memory-constrained targets where ASan is not.

ThreadSanitizer takes a different route, because data races are a concurrency property rather than a property of a single access. The README links separate manuals for the C++ and Go implementations, and the existence of two manuals is the interesting part: the same detector is described differently depending on whether the language runtime gives it scheduling hooks. MemorySanitizer detects use of uninitialized memory, which requires tracking initialization state through computation, not just checking addresses, and that is why it is the most demanding of the set to use on a partially instrumented program.

The repository layout reflects this split. memory-sanitizer/, hwaddress-sanitizer/, gwp-asan/ and mte-dynamic-carveout/ sit alongside android/ and buildbot/, which is the shape of a project whose real output is compiler instrumentation and whose repository is the surrounding documentation and infrastructure.

Installing and using AddressSanitizer: a first real run

There is no install step for this repository, and the README gives none. The sanitizers come with the compiler you already use, and the README directs runtime and instrumentation bugs to LLVM, so the practical route is to build your program with the sanitizer enabled. The README does not print the flag spelling, so confirm it against your compiler's own documentation before you rely on it; the repository's wiki pages under the AddressSanitizer heading are where the historical usage notes live.

The README's documentation list is the map for this. AddressSanitizer and LeakSanitizer are documented together under the AddressSanitizer wiki entry, ThreadSanitizer has separate C++ and Go manuals, MemorySanitizer has its own page, and HWASAN is described in the Clang documentation rather than in this repository. Start with the page for the detector that matches your bug class, not with the repository as a whole.

One warning that follows from the README's structure rather than from a command: the detectors are documented as separate tools with separate manuals, so do not expect a single build flag to cover addressability, races and uninitialized reads at once. Pick the detector for the failure you are chasing, build, run, and read the report against the wiki page for that detector.

Where this repository stops being the right answer

The README is explicit that the repository is archived and that new bug reports should not be filed here. That is the first limitation and it is not cosmetic. If you find a false positive in AddressSanitizer, a missing report in MemorySanitizer, or a ThreadSanitizer failure that does not reproduce, this repository is the wrong place to look for a fix, and the README redirects you by component: LLVM for runtime and instrumentation bugs, GCC Bugzilla for the GCC port, the Linux kernel mailing list for KASAN, KMSAN and KCSAN, the Android NDK tracker for Android, and the Apple or Microsoft vendor channels for Xcode and Visual Studio compilers.

There is a second, quieter limitation. The documentation linked from the README is labelled archived. Wiki pages that describe flags, environment variables or supported platforms may have been accurate when they were written and may not describe the compiler you have now. A reader who treats this repository as the current source of truth for sanitizer behaviour is reading a snapshot, and the README itself frames the contents as retained for archival purposes.

Finally, the sanitizers are the wrong tool for some jobs regardless of repository status. MemorySanitizer needs your dependencies instrumented too, or it reports uninitialized values that originate outside your code, and that is a build-system project rather than a compiler flag. Kernel work has its own variants, KASAN, KMSAN and KCSAN, documented separately and reported through kernel channels.

Valgrind and the sanitizer approach differ in where the cost lands

The natural alternative for memory debugging is Valgrind, and the difference is architectural. Valgrind runs your unmodified binary on a synthetic CPU, so you do not rebuild anything, but every instruction pays the emulation cost. The sanitizers instrument at compile time, so the checks are inserted into your code and the resulting binary runs natively with a shadow-memory lookup on the accesses that matter. That is why sanitizer builds are typically fast enough to run a test suite while Valgrind is often reserved for a single reproduction.

The trade-off runs the other way too. A Valgrind run needs no source and no rebuild, which makes it usable on a binary you cannot recompile, and it detects some classes of error through its own tool set rather than through compiler support. The sanitizers, by contrast, are tied to the compiler that produced the binary and to the runtime that ships with it. The README's list of bug destinations, split across LLVM, GCC, the kernel, Android, Apple and Microsoft, is a direct consequence of that coupling: the same detector behaves differently depending on which toolchain built it.

Maintenance status, licensing and what to check before citing this repository

The README states plainly that the repository has been archived and is no longer actively maintained. The last push recorded for the repository is 2026-09-09, which is recent, but the archival notice governs how that should be read: the README says the repository will be retained for archival purposes, and it asks that new bug reports go elsewhere. Do not treat commit activity here as evidence that the sanitizers are developed in this repository, because the README says the core code resides in LLVM.

The LICENSE.TXT file is present at the top level, but the repository metadata reports the licence as NOASSERTION, meaning no standard identifier was detected. The README does not discuss licensing terms. If you intend to reuse helper code from directories such as android/ or dashboard/, read LICENSE.TXT directly and confirm the terms with your own legal review rather than assuming a standard open source licence applies.

Upgrade cost is close to zero for the sanitizers themselves, because they arrive with your compiler: upgrading the toolchain upgrades the detectors. The cost sits in this repository. Any wiki page, helper script or historical bugfix you depend on here has no maintainer behind it, and the README points you to LLVM, GCC, the kernel, Android, Apple or Microsoft for anything that still needs fixing.

Editorial conclusion

Adopt the sanitizers themselves, not this repository. If you are chasing memory or concurrency bugs in C or C++, the tools are AddressSanitizer, ThreadSanitizer and MemorySanitizer, and the README states their core code resides in LLVM. Do not adopt google/sanitizers as a dependency, a bug tracker or a source of current documentation, because the README says the repository is archived and asks that new bug reports go to the LLVM Bug Tracker, GCC Bugzilla, or the relevant kernel, Android, Apple or Microsoft channel. Before citing any wiki page here, check whether an equivalent page exists in the LLVM documentation, since the README labels this material archived. If you hit a sanitizer bug, reproduce it against a trunk compiler first and file it where the README points, not here.

Frequently asked questions

Official sources

1. google/sanitizers on GitHub
2. Issues
3. README