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

Previous Next

Full log

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.

Previous Next

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