Subject: Re: bug#76393: Warn about -fsanitizer=address builds

From: Pip Cet <[email-masked]>
Date: Tue, 18 Feb 2025 17:24:26 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Date: Tue, 18 Feb 2025 15:48:44 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: [email-masked], [email-masked]
>>
>> "Eli Zaretskii" <[email-masked]> 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