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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76393 in the body.
You can then email your comments to 76393 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Pip Cet <pipcet <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Warn about -fsanitizer=address builds
Date: Tue, 18 Feb 2025 12:34:08 +0000

Building with current GCC and -fsanitizer=address results in certain
(large) stack allocations being performed on a "fake stack", using
__asan_stack_malloc_N.  This "fake stack" is invisible to GC and thus
breaks conservative GC scanning (bug#76327).

It seems to be possible to work around this by setting

ASAN_OPTIONS=detect_stack_use_after_return=0

Even with that option, a "sanitized" build reports bogus errors.

ASAN_OPTIONS=detect_stack_use_after_return=0,detect_leaks=0

seems to work, at least, but is it really worth it to keep adding
options (inconveniently using environment variables) to work around such
ASAN bugs?

I think it would be preferrable to warn about builds with
-fsanitizer=address, which generates broken code, or disable them
entirely.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
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:25:32 +0200

> Date: Tue, 18 Feb 2025 12:34:08 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Building with current GCC and -fsanitizer=address results in certain
> (large) stack allocations being performed on a "fake stack", using
> __asan_stack_malloc_N.  This "fake stack" is invisible to GC and thus
> breaks conservative GC scanning (bug#76327).
> 
> It seems to be possible to work around this by setting
> 
> ASAN_OPTIONS=detect_stack_use_after_return=0
> 
> Even with that option, a "sanitized" build reports bogus errors.
> 
> ASAN_OPTIONS=detect_stack_use_after_return=0,detect_leaks=0
> 
> seems to work, at least, but is it really worth it to keep adding
> options (inconveniently using environment variables) to work around such
> ASAN bugs?
> 
> I think it would be preferrable to warn about builds with
> -fsanitizer=address, which generates broken code, or disable them
> entirely.

If what we have in etc/DEBUG about building with address sanitization
is not enough or outdated, please consider updating and expanding that
section.

Message #11 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 15:48:44 +0000

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

>> Date: Tue, 18 Feb 2025 12:34:08 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Building with current GCC and -fsanitizer=address results in certain
>> (large) stack allocations being performed on a "fake stack", using
>> __asan_stack_malloc_N.  This "fake stack" is invisible to GC and thus
>> breaks conservative GC scanning (bug#76327).
>>
>> It seems to be possible to work around this by setting
>>
>> ASAN_OPTIONS=detect_stack_use_after_return=0
>>
>> Even with that option, a "sanitized" build reports bogus errors.
>>
>> ASAN_OPTIONS=detect_stack_use_after_return=0,detect_leaks=0
>>
>> seems to work, at least, but is it really worth it to keep adding
>> options (inconveniently using environment variables) to work around such
>> ASAN bugs?
>>
>> I think it would be preferrable to warn about builds with
>> -fsanitizer=address, which generates broken code, or disable them
>> entirely.
>
> 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.

So here's the documentation part; I'd like to change configure.ac as
well, but the doc part should come first.

From 96e3e05a8a636b205ba204a222dc2eb98a45d4fa Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet <at> protonmail.com>
Subject: [PATCH] Warn about -fsanitize=address (bug#76393)

* etc/DEBUG (Running Emacs with address sanitization): Explain
currently-known problems when building with -fsanitize=address.
---
 etc/DEBUG | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/etc/DEBUG b/etc/DEBUG
index ca061063454..95c2180fb18 100644
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -1010,14 +1010,20 @@ program.
 ** Running Emacs with address sanitization
 
 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.
+
+To use AddressSanitizer with GCC and similar compilers, append
 '-fsanitize=address' to CFLAGS, either when running 'configure' or
 running 'make'.  Configure, build and run Emacs with
-ASAN_OPTIONS='detect_leaks=0' in the environment to suppress
-diagnostics of minor memory leaks in Emacs.  For example:
+ASAN_OPTIONS='detect_stack_use_after_return=0,detect_leaks=0' in the
+environment to suppress diagnostics of minor memory leaks in Emacs, and
+buggy code which relocates objects from the stack to the heap .  For
+example:
 
-  export ASAN_OPTIONS='detect_leaks=0'
+  export ASAN_OPTIONS='detect_stack_use_after_return=0,detect_leaks=0'
   ./configure CFLAGS='-O0 -g3 -fsanitize=address'
   make
   src/emacs
-- 
2.48.1

Pip

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

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

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

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

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
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 21:35:23 +0200

> Date: Tue, 18 Feb 2025 17:24:26 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: eggert <at> cs.ucla.edu, 76393 <at> debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> > 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.

I'm not familiar with -fanalyze=address.  Does disabling it still
allow to use address sanitization? if so, perhaps we should recommend
using -fno-analyze=address when building for ASAN?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 76393 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Tue, 18 Feb 2025 16:50:14 -0800

On 2/18/25 07:48, Pip Cet wrote:
>   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.

I don't see a GCC bug there. What I see is an incompatibility with 
Emacs's garbage collector, a collector which relies on several aspects 
of undefined behavior in C. So I suggest changing the last three lines 
to something like this:

as the default behavior of -fsanitize=address is incompatible with 
ordinary Emacs operation, it needs to be combined with other options.


> +ASAN_OPTIONS='detect_stack_use_after_return=0,detect_leaks=0' in the
> +environment to suppress diagnostics of minor memory leaks in Emacs, and
> +buggy code which relocates objects from the stack to the heap .  For
> +example:

Here, change "buggy code which relocates" to "to suppress relocation 
of". Also, omit the space before ".".

Otherwise, it looks good.

I've found -fsanitize=address to be verrrrry helpful when debugging 
obscure memory problems, and it's good to document how to use it.

It would be even better if we changed Emacs so that ASAN_OPTIONS need 
not contain set detect_stack_use_after_return=0, as that would help 
detect more errors. -fsanitize=address has support for this sort of 
thing; see its __asan_addr_is_in_fake_stack function. However, Emacs 
currently doesn't use that support, so we must currently settle for 
detect_stack_use_after_return=0.

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

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

"Paul Eggert" <eggert <at> cs.ucla.edu> writes:

> On 2/18/25 07:48, Pip Cet wrote:
>>   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.
>
> I don't see a GCC bug there.

I understand the desire to be diplomatic here, and I'll adjust the patch
accordingly, but I don't agree: fake stacks are a rashly-implemented
manipulation, violating established ABI conventions, which will cause
false positives which are then hard to debug because none of them are
documented sufficiently, and the error messages provide no indication
that the sanitizer is to blame.

> What I see is an incompatibility with Emacs's garbage collector, a
> collector which relies on several aspects of undefined behavior in
> C. So I suggest changing the last three lines to something like this:

The idea that any significant program can rely only on defined behavior
of C is nice, but it's not even close to being true.

> as the default behavior of -fsanitize=address is incompatible with
> ordinary Emacs operation, it needs to be combined with other options.

It is important to point out that these bugs do not mention the
sanitizer in the crash report, and that the only "option" to make GCC
generate correct code is an environment variable, which is error-prone
and inconvenient.

>> +ASAN_OPTIONS='detect_stack_use_after_return=0,detect_leaks=0' in the
>> +environment to suppress diagnostics of minor memory leaks in Emacs, and
>> +buggy code which relocates objects from the stack to the heap .  For
>> +example:
>
> Here, change "buggy code which relocates" to "to suppress relocation
> of".

Again, happy to make the change if the decision is to remain diplomatic
here.  If the option were "no_fake_stack=1", I'd agree.  But the option
isn't called that: there is no ASAN option to insist on a traditional
stack, we can only disable the various "features" which incidentally
violate traditional stack assumptions.  Today, it's
'detect_stack_use_after_return', but there's no guarantee (or
documentation) of that.

> Also, omit the space before ".".

Oops.  I'd written more there :-)

> Otherwise, it looks good.
>
> I've found -fsanitize=address to be verrrrry helpful when debugging
> obscure memory problems, and it's good to document how to use it.

Well, it hasn't worked for a while.

> It would be even better if we changed Emacs so that ASAN_OPTIONS need
> not contain set detect_stack_use_after_return=0, as that would help
> detect more errors. -fsanitize=address has support for this sort of
> thing; see its __asan_addr_is_in_fake_stack function. However, Emacs
> currently doesn't use that support, so we must currently settle for
> detect_stack_use_after_return=0.

__asan_get_current_fake_stack is marked for removal in GCC, and it's not
quite clear whether that comment applies to
__asan_addr_is_in_fake_stack, too.  However, I don't see how either
function would help us detect all the fake stacks and their extents.

There is an established API for split stacks, implemented by
-fsplit-stack (Emacs doesn't support it by default, but I wrote a patch
to add support, and it's not hard).  ASAN doesn't use it, and the
alternatives it provides are unusable, so I'm skeptical that it's a tool
which is worth the significant effort to "support" it.

Pip

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 76393 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Wed, 19 Feb 2025 09:37:59 -0800

On 2025-02-19 04:18, Pip Cet wrote:

> fake stacks are a rashly-implemented
> manipulation, violating established ABI conventions

Yes, just as CheriBSD is rashly implemented and violates many ABI 
conventions. Still, CheriBSD is a useful way to find bugs that would 
otherwise be very difficult to squash (I've found some, with other GNU 
projects), and it's worth using for that reason. Although CheriBSD 
doesn't work with Emacs, if we could get it to work without too much 
trouble, that'd likely find Emacs bugs better than what we have now.


> The idea that any significant program can rely only on defined behavior
> of C is nice, but it's not even close to being true.

The C standard is a diplomatic agreement between implementers and users 
that nobody likes and everybody argues about. That being said, it's 
better than nothing and it's better to be diplomatic.


> point out that these bugs do not mention the
> sanitizer in the crash report

Fair enough.

> and that the only "option" to make GCC
> generate correct code is an environment variable, which is error-prone
> and inconvenient.

This is too strong. I don't find the env var to be significantly more 
error-prone and inconvenient than the hassle of using 
-fsanitizer=address in the first place.


> If the option were "no_fake_stack=1", I'd agree.  But the option
> isn't called that

I doubt whether it's worth our time to dispute how a GCC runtime option 
is spelled.



>> I've found -fsanitize=address to be verrrrry helpful when debugging
>> obscure memory problems, and it's good to document how to use it.
> 
> Well, it hasn't worked for a while.

I expect that's because I haven't debugged Emacs in a while - at least, 
I haven't debugged it with some of its new bells and whistles that make 
it less reliable. If I ever get back into the Emacs debugging business, 
though, I'd like to have the -fsanitize=address option at my disposal. 
Although no cureall, it's a valuable tool.


> __asan_get_current_fake_stack is marked for removal in GCC, and it's not
> quite clear whether that comment applies to
> __asan_addr_is_in_fake_stack, too.  However, I don't see how either
> function would help us detect all the fake stacks and their extents.

We'd plant a function (or macro) call in every function for which GCC 
creates a fake stack frame that might contain Lisp Objects. The function 
would be a no-op unless address sanitization is in use (or better yet, 
unless fake stacks are in use). It's not hard to find which functions 
these would be.

It's not clear to me whether this would be worth the hassle; but I don't 
see why it wouldn't be doable.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: pipcet <at> protonmail.com, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76393 <at> debbugs.gnu.org
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sat, 01 Mar 2025 14:18:58 +0200

Ping!  Can we make progress with this issue, please?

> Date: Tue, 18 Feb 2025 16:50:14 -0800
> Cc: 76393 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 2/18/25 07:48, Pip Cet wrote:
> >   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.
> 
> I don't see a GCC bug there. What I see is an incompatibility with 
> Emacs's garbage collector, a collector which relies on several aspects 
> of undefined behavior in C. So I suggest changing the last three lines 
> to something like this:
> 
> as the default behavior of -fsanitize=address is incompatible with 
> ordinary Emacs operation, it needs to be combined with other options.
> 
> 
> > +ASAN_OPTIONS='detect_stack_use_after_return=0,detect_leaks=0' in the
> > +environment to suppress diagnostics of minor memory leaks in Emacs, and
> > +buggy code which relocates objects from the stack to the heap .  For
> > +example:
> 
> Here, change "buggy code which relocates" to "to suppress relocation 
> of". Also, omit the space before ".".
> 
> Otherwise, it looks good.
> 
> I've found -fsanitize=address to be verrrrry helpful when debugging 
> obscure memory problems, and it's good to document how to use it.
> 
> It would be even better if we changed Emacs so that ASAN_OPTIONS need 
> not contain set detect_stack_use_after_return=0, as that would help 
> detect more errors. -fsanitize=address has support for this sort of 
> thing; see its __asan_addr_is_in_fake_stack function. However, Emacs 
> currently doesn't use that support, so we must currently settle for 
> detect_stack_use_after_return=0.
> 

Message #37 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, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sat, 01 Mar 2025 13:57:22 +0000

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

> Ping!  Can we make progress with this issue, please?

Is this sufficiently diplomatic?  It also removes a reference to unexec
that somehow survived the no-purespace merge :-)

By the way, I think I'm responsible for the "minor" memory leak that
happens during pdumping, because the hash table freezing code duplicates
the hash table and never freezes the original copy.  Trying to fix that
now, though I don't think leaking memory during pdumper is a high
priority.

Pip

From 95bbb25afcafa24edb5b31dbf28a41378bd90fa7 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet <at> protonmail.com>
Subject: [PATCH] Improve instructions for running with -fsanitize=address
 (bug#76393)

* etc/DEBUG (ASAN_OPTIONS): Add 'detect_stack_use_after_return=0'
requirement.  Remove obsolete unexec commentary.
---
 etc/DEBUG | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/etc/DEBUG b/etc/DEBUG
index ca061063454..b95ea7e7e8c 100644
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -1010,14 +1010,16 @@ program.
 ** Running Emacs with address sanitization
 
 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.  It does, however,
+require special care to ensure that Emacs's garbage collection continues
+working.  To use AddressSanitizer with GCC and similar compilers, append
 '-fsanitize=address' to CFLAGS, either when running 'configure' or
-running 'make'.  Configure, build and run Emacs with
-ASAN_OPTIONS='detect_leaks=0' in the environment to suppress
-diagnostics of minor memory leaks in Emacs.  For example:
+running 'make'.  When running Emacs, ensure the ASAN_OPTIONS environment
+variable is set and includes 'detect_stack_use_after_return=0' (to keep
+GC working) and 'detect_leaks=0' (to avoid noisy diagnostics about minor
+memory leaks in Emacs).  For example:
 
-  export ASAN_OPTIONS='detect_leaks=0'
+  export ASAN_OPTIONS='detect_leaks=0,detect_stack_use_after_return=0'
   ./configure CFLAGS='-O0 -g3 -fsanitize=address'
   make
   src/emacs
@@ -1034,8 +1036,7 @@ will let you gain control when an error is detected and before
 AddressSanitizer outputs to stderr or terminates the program.
 
 Address sanitization is incompatible with undefined-behavior
-sanitization, unfortunately.  Address sanitization is also
-incompatible with the --with-dumping=unexec option of 'configure'.
+sanitization, unfortunately.
 
 *** Address poisoning/unpoisoning
 
-- 
2.48.1

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> protonmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 76393 <at> debbugs.gnu.org
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sat, 1 Mar 2025 12:42:54 -0800

On 2025-03-01 05:57, Pip Cet wrote:
> Is this sufficiently diplomatic?

Thanks, looks good.

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76393-done <at> debbugs.gnu.org
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sat, 01 Mar 2025 21:42:27 +0000

"Paul Eggert" <eggert <at> cs.ucla.edu> writes:

> On 2025-03-01 05:57, Pip Cet wrote:
>> Is this sufficiently diplomatic?
>
> Thanks, looks good.

Thanks! Pushed, and closing.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 76393 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sun, 02 Mar 2025 07:35:49 +0200

> Date: Sat, 01 Mar 2025 21:42:27 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76393-done <at> debbugs.gnu.org
> 
> "Paul Eggert" <eggert <at> cs.ucla.edu> writes:
> 
> > On 2025-03-01 05:57, Pip Cet wrote:
> >> Is this sufficiently diplomatic?
> >
> > Thanks, looks good.
> 
> Thanks! Pushed, and closing.

Thanks.

Are the changes appropriate for the release branch as well?  If so,
I'd like to backport them to emacs-30.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Pip Cet <pipcet <at> protonmail.com>
Cc: 76393 <at> debbugs.gnu.org
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sat, 1 Mar 2025 22:52:18 -0800

On 2025-03-01 21:35, Eli Zaretskii wrote:
> Are the changes appropriate for the release branch as well?

Yes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76393 <at> debbugs.gnu.org, pipcet <at> protonmail.com
Subject: Re: bug#76393: Warn about -fsanitizer=address builds
Date: Sun, 02 Mar 2025 09:13:27 +0200

> Date: Sat, 1 Mar 2025 22:52:18 -0800
> Cc: 76393 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 2025-03-01 21:35, Eli Zaretskii wrote:
> > Are the changes appropriate for the release branch as well?
> 
> Yes.

Thanks, backported to emacs-30.

Previous Next

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