GNU bug report logs - #76393
Warn about -fsanitizer=address builds

Previous Next

Full log

Message #17 received at 76393 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76393 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Tue, 18 Feb 2025 17:24:26 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Date: Tue, 18 Feb 2025 15:48:44 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: 76393 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
>>
>> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>>
>> > If what we have in etc/DEBUG about building with address sanitization
>> > is not enough or outdated, please consider updating and expanding that
>> > section.
>>
>> Since we detect asan builds, and we know them to be broken, we should
>> probably warn about it in configure.ac as well.  I strongly suspect that
>> if ASAN sees further development, it will break Emacs in new ways, and
>> that'll be hard to debug.
>
> I think it's too early for that.  I don't see enough people using such
> builds, so I think for now having that in etc/DEBUG is enough.
> There's no need to complicate everyone's life because one or two
> people want sometimes to use ASAN.

Okay, Paul's opinion would definitely be appreciated.

>> So here's the documentation part; I'd like to change configure.ac as
>> well, but the doc part should come first.
>
> LGTM in general, with one question below.  But I'd like to hear Paul's
> opinion on this as well.

Sure, no rush here.

>>  Building Emacs with address sanitization can help debug memory-use
>> -problems, such as freeing the same object twice.  To use
>> -AddressSanitizer with GCC and similar compilers, append
>> +problems, such as freeing the same object twice.  However,
>> +-fsanitize=address also introduces bugs in the compiled code which cause
>> +GC problems and phantom crashes, which do not always look like they're
>> +caused by the address sanitizer.
>
> When you say "bugs in compiled code", do you mean the code in the
> Emacs executable, or do you mean the bytecode or native code emitted

The code put by GCC -fanalyzer into the Emacs executable does buggy
things unless an environment variable is set to make it not do those
things.

> by compiling Lisp?  If the former, isn't that a GCC bug?  And if so,

It is, yes: GCC violates the unwritten contract by which conservative GC
works when compiling with -fanalyze=address, by moving stack structs to the
heap.

> perhaps there are some -fSOMETHING switches which avoid hitting those
> bugs?

-fno-analyze=address?  Ideally, GCC should be passed by Emacs an option
to ensure it won't break conservative GC, but I'm not aware of such an
option.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.