From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Victoria Dye <vdye@github.com>
Subject: Re: [PATCH] Makefile: suppress annotated leaks with certain ASan options
Date: Fri, 20 Jan 2023 12:46:59 -0800 [thread overview]
Message-ID: <xmqqmt6dvsqk.fsf@gitster.g> (raw)
In-Reply-To: <Y8r2Tn75g52YTIij@coredump.intra.peff.net> (Jeff King's message of "Fri, 20 Jan 2023 15:15:10 -0500")
Jeff King <peff@peff.net> writes:
> I do think there's some complexity here, though.
>
> One problem UNLEAK() is that compile-time switch, but whether ASan does
> leak detection is a run-time choice. So you are stuck with either:
>
> - you always turn on UNLEAK() for ASan builds, in which case test runs
> using the default ASAN_OPTIONS we set do the extra work even though
> they are not doing any leak detection. I doubt it's very measurable,
> though (it's just shoving a few bytes onto a linked list),
> especially compared to the overall slowness of ASan.
>
> - you predicate the build-time choice on ASAN_OPTIONS. But this means
> that:
>
> make SANITIZE=address
> cd t
> ASAN_OPTIONS=detect_leaks=1 ./t0000-*.sh
>
> will confusingly fail to use UNLEAK().
>
> Your patch does the second one, but I think the first may be the
> least-bad option.
Thanks, I totally missed the fact that ASAN_OPTIONS was a runtime
thing. If we were to pursue this topic of enabling UNLEAK() outside
LSan, I agree the first would be necessary.
> But for leak-checking, we've already seen real cases where using LSan
> with higher optimization levels can lead to false positives (because the
> optimizer drops a value that is still in scope but not used in a code
> path that leads to exit()).
> ...
> So it may be that we really do want to keep leak-checking to "-O0
> -fsanitize=leak", and reserve "-O2 -fsanitize=address" for finding
> address bugs.
Yup, we have been burned a few times with this, IIRC.
next prev parent reply other threads:[~2023-01-20 20:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 18:46 [PATCH] Makefile: suppress annotated leaks with certain ASan options Taylor Blau
2023-01-20 19:41 ` Junio C Hamano
2023-01-20 20:15 ` Jeff King
2023-01-20 20:46 ` Junio C Hamano [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmt6dvsqk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=vdye@github.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.