HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
google
sanitizers
C2016–2025
google / sanitizers

sanitizers

AddressSanitizer, ThreadSanitizer, MemorySanitizer

47Distinct people
55Mentions
1Explicit recommenders
12.5KGitHub stars
REPOSITORY AT A GLANCE

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, 12:45:45 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.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC716
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC615
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC624
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC514
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC312
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC606
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC707
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC707

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 GitHub

What Hacker News says

7 sources
One of the sanitizer guys tested the mpx instructions on skylake [1]. Tl;dr - Kind of underwhelming. But then, skylake is just the first iteration. > What was the portability issue? Oh, it was a long time ago that I investigated it and I don't remember the details very clearly, but for one, I needed a solution that supported Windows. Either it didn't support Windows, or its support for Windows was obsolete or something. I don't really remember. And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not. Yeah, I don't really remember the details, but it wasn't my intention to develop SaferCPlusPlus. If I could've gotten Ironclad to work for me, I probably would've been happy with that. > This would be a good selling point to enterprise customers Yeah, unfortunately I'm not
Read the rest
selling anything, otherwise there would be marketing budget :) [1] https://github.com/google/sanitizers/wiki/AddressSanitizerIn...
In OpenSSL after Heartbleed
Perhaps an editor could mark this (2016) despite this being the opposite of the usual custom? I've learned not to get excited when someone posts one a Dan Luu article, since it's usually something old that I've already seen. But despite the lack of a date at the top, and despite starting with references to 2010 and 2008 papers, this one is actually new! On further thought, maybe it would better to change the title to claim it's from (2010), wait for enough people to complain, then "something", then use that momentum to convince Dan to finally put dates on his articles. Just need to figure out what that "something" should be... -- I looked into Thread Sanitizer (libtsan) recently, and was happy to see that it's supported on recent GCC as well. Documentation is a little strange, as it's split between a Google Wiki on Github and Clang, w
Read the rest
hile the source is in LLVM: https://github.com/google/sanitizers/wiki/ThreadSanitizerCpp... http://clang.llvm.org/docs/ThreadSanitizer.html https://llvm.org/svn/llvm-project/llvm/trunk/lib/Transforms/... I was spooked by this FAQ on the Google Wiki page, though: Q: My code with C++ exceptions does not work with tsan. A: Tsan does not support C++ exceptions. Does this mean that it does not work at all on code that is written with exceptions, or that it might have false-positives or false-negatives when exceptions actually happen at runtime? -- For other tools, Intel has offers their "Parallel Inspector": https://software.intel.com/en-us/intel-inspector-xe. I haven't tried it, but it sounds like it would be useful for these issues: https://software.intel.com/en-us/get-started-with-inspector. Does anyone know how it compares with TSan? -- An example of an atomicity violation is this bug from MySQL: Thread 1: if (thd->proc_info) fputs(thd->proc_info, ...) Thread 2: thd->proc_info = NULL; While definitely a concurrency bug, I'm surprised that this would happen frequently enough to create numerous bug reports unless there is also an undesired compiler optimization that's removing the "guard" in Thread 1. That is, the window of opportunity seems very small if the code is being executed as written. I didn't look at the details of the linked bug reports, but I suspect the compiler is able to reason based on something earlier that thd->proc_info must be non-null at this point, and thus has omitted the check. If this is the case, it's possible that "Stack" would have caught this bug as well, or at least highlighted it as a place where the generated code was different than the programmer's intent. Stack is painful to install, and seems abandoned, but does catch flag some bugs that other tools miss: https://github.com/xiw/stack/ -- Does anyone know of other tools in this space? I'm still hoping there's a "silver bullet" I haven't found yet.
In Notes on concurrency bugs

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.