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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 18 Feb 2025 19:08:41 +0200

> 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.

> 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.

>  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
by compiling Lisp?  If the former, isn't that a GCC bug?  And if so,
perhaps there are some -fSOMETHING switches which avoid hitting those
bugs?