mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
Cc: Derrick Stolee <>,
	Jeff King <>,
	Johannes Schindelin <>,
	Junio C Hamano <>,
	Victoria Dye <>
Subject: [PATCH] Makefile: suppress annotated leaks with certain ASan options
Date: Fri, 20 Jan 2023 13:46:16 -0500	[thread overview]
Message-ID: <> (raw)

When building with `SANITIZE=leak`, we define `SUPPRESS_ANNOTATED_LEAKS`
in order to make the `UNLEAK()` macro work (without the aforementioned
define, `UNLEAK()` is a noop). This is from `UNLEAK()`'s introduction in
0e5bba53af (add UNLEAK annotation for reducing leak false positives,
2017-09-08), where `UNLEAK()` is a noop for performance reasons unless
we are using the leak sanitizer.

However, it is possible to use the leak sanitizer without
`SANITIZE=leak`. This happens when building with `SANITIZE=address` and
enabling the leak sanitizer via the `ASAN_OPTIONS` variable (by
including the string "detect_leaks=1").

This renders `UNLEAK()` useless when doing `SANITIZE=address` builds
which also use the leak checker.

Update our Makefile to pretend as if `SANITIZE=leak` was given when
`SANITIZE=address` is given and the leak checker is enabled via

Playing around with all five options (two spelling "enabled", two
spelling "disabled", and the empty set of options) yields the correct

    for opt in '' detect_leaks=1 detect_leaks=true detect_leaks=0 detect_leaks=false
      echo "==> ${opt:-(nothing)}"
      make -B builtin/add.o V=1 SANITIZE=address ASAN_OPTIONS="$opt" 2>&1 |
        grep -o -- '-DSUPPRESS_ANNOTATED_LEAKS'

gives us:

    ==> (nothing)
    ==> detect_leaks=1
    ==> detect_leaks=true
    ==> detect_leaks=0
    ==> detect_leaks=false

Making it possible to rely on `UNLEAK()` when implicitly using the leak
checker via SANITIZE=address builds.

Signed-off-by: Taylor Blau <>
I found this while playing around with GitHub's ASan-enabled CI builds
for our internal fork following a merge with v2.38.3.

The check-chainlint recipe in t/Makefile started using "git diff" via
d00113ec34 (t/Makefile: apply to existing self-tests,
2022-09-01), which triggered a leak in some of GitHub's custom code. I
was surprised when marking the variable with UNLEAK() didn't do the
trick, and ended up down this rabbit hole ;-).

 Makefile | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index db447d0738..b00bb8bd1e 100644
--- a/Makefile
+++ b/Makefile
@@ -1445,13 +1445,18 @@ ifneq ($(filter undefined,$(SANITIZERS)),)
 ifneq ($(filter leak,$(SANITIZERS)),)
 SANITIZE_LEAK = YesCompiledWithIt
 ifneq ($(filter address,$(SANITIZERS)),)
+ifeq ($(filter $(patsubst detect_leaks=%,%,$(ASAN_OPTIONS)),0 false),)
+SANITIZE_LEAK = YesViaASanOptions
+ifneq ($(SANITIZE_LEAK),)


             reply	other threads:[~2023-01-20 18:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 18:46 Taylor Blau [this message]
2023-01-20 19:41 ` [PATCH] Makefile: suppress annotated leaks with certain ASan options Junio C Hamano
2023-01-20 20:15 ` Jeff King
2023-01-20 20:46   ` Junio C Hamano
2023-01-20 20:55   ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).