AddressSanitizer is another approach to detect memory-related (including stack overflow) errors in C and C++ programs. See https://github.com/google/sanitizers/wiki/AddressSanitizer
In Hardening C/C++ Programs: Stack Protectorgoogle
sanitizers
C2016–2025
google / sanitizers
sanitizers
AddressSanitizer, ThreadSanitizer, MemorySanitizer
47Distinct people
55Mentions
1Explicit recommenders
12.5KGitHub stars
What to know before exploring
What it is
AddressSanitizer, ThreadSanitizer, MemorySanitizer
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Yep. Theoretically it is possible but libasan is not intended for linking or shipping in production. Also stuff like LeakSanitizer[1] actually cannot [1] be used with GDB.…
ho_schi used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year55 dated mentions
Observed mentions: 2016-01-15 13:30:51 UTC to 2025-11-23 12:47:34 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 0 | 7 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
sanitizers (Archived)
This repository has been archived and is no longer actively maintained.
The Sanitizers repository, which includes AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer, and more, is now archived. The core code for these sanitizers resides within the LLVM repository. This repository will be retained for archival purposes, providing access to historical documentation, bugfixes, and helper code.
Important: Please do not file new bug reports in this repository.
Where to Report Bugs:
LLVM: For bugs related to the sanitizer runtimes and instrumentation, please report them to the LLVM Bug Tracker.
GCC: For bugs related to the GCC port of the sanitizers, please report them to the GCC Bugzilla.
Linux Kernel: For bugs related to Kernel AddressSanitizer (KASAN), Kernel MemorySanitizer (KMSAN), or Kernel ConcurrencySanitizer (KCSAN), please report them through the appropriate Linux kernel bug reporting channels, such as the Linux kernel mailing list.
Linux Distributions: For bugs related to compiler issues in specific Linux distributions that are not reproducible in trunk compilers, please report them to the respective distribution's bug tracker (e.g., Debian Bug Tracking System, Red Hat Bugzilla).
Apple and Microsoft: For bugs related to the compilers provided by Apple (Xcode) or Microsoft (Visual Studio), please report them through the respective vendor's bug reporting channels.
Android NDK: For bugs related to Android, please report them to the NDK issue tracker.
Documentation (Archived):
AddressSanitizer (detects addressability issues) and LeakSanitizer (detects memory leaks)
ThreadSanitizer (detects data races and deadlocks) for C++ and Go
MemorySanitizer (detects use of uninitialized memory)
HWASAN, or Hardware-assisted AddressSanitizer, a newer variant of AddressSanitizer that consumes much less memory
UBSan, or UndefinedBehaviorSanitizer
Kernel Sanitizers (Archived Documentation):
KASAN
KMSAN
KCSAN
Thank you for your understanding.
Read the full README on GitHubWhat Hacker News says
6 sources> We guarantee type and memory safety by introducing a
new exception (DanglingReferenceException) with the
following semantics: a dereference to a deleted object
will either succeed as if that very object was not yet
deleted, or result in a DanglingReferenceException.
I would worry about what might happen in a variable-sized object reuse/freelist type scheme combined with this allocator. A dangling reference might not contain garbage that allows an attacker to control program flow, while still containing data that is exploitable in other ways.
So this is not an entirely safe way to do things. Arguably it would be worth the speedup. But many of the techniques for making this approach safe . . .
> such exceptions can be detected with the combination of rigorous testing and support in the allocator for a debug mode that enforces stronger sem
Read the rest
antics (i.e. exceptions on every dereference to a deleted object) at a higher cost
. . . can also be used to test C++. For example, we use https://github.com/google/sanitizers a lot at the office to detect these sorts of errors.
Still, an interesting and clever result. Nicely done!
> Present != Equal, feature wise.
It is developed by google[0] afaik. The link says it is present in LLVM and gcc. I don't know what makes the difference (may be License?). On the contrary I have felt gcc better for my work. I have been following a clang bug[1] for long and have seen no fix so far.
[0] https://github.com/google/sanitizers/wiki/AddressSanitizer
[1] https://bugs.llvm.org/show_bug.cgi?id=23910
In Building the Linux kernel with clangNot sure if this is exactly what you are asking, but there's tsan (ThreadSanitizer):
https://github.com/google/sanitizers/wiki/ThreadSanitizerCpp...
In A formal kernel memory-ordering modelAnd don't forget the llvm (and gcc) sanitizers[1] and SaferCPlusPlus[2] (essentially a memory safe subset of C++), which are more modern and have arguably better overall combinations of performance/safety/compatibility/practicality.
Automatic translation (assistance) from native C to SaferCPlusPlus is being worked on. And if you'll permit me to gripe a little here - you might think it's a reasonable undertaking, until you start contemplating code like this:
int **var1 = (int **)malloc(20);
var1[2] = (int *)malloc(10);
int *var2 = var1[2] + 4;
var2--;
free(var2 - 3);
free(var1);
:)
[1] https://github.com/google/sanitizers
[2] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
In The Safe C Library (2009)Address Sanitizer in Hardware (proposal)
1 points · Open discussion