bug#57751: 29.0.50; crash in GC

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Sam Steingold <sds@gnu.org> writes:

>> (If you use it for building Emacs, you'll need to "brew install bear",
>> or remove the call to bear in the script.  Also, you might want to use
>> --elc if you don't use native compilatin.)
>
> I think native compilation is disabled on mac by default.

That's correct.  I was mentioning --elc only because make-emacs defaults
to configuring --with-native-compilation, because I'm using that 99% of
the time.

> I build my normal Emacs out of the tree, so the source tree is already
> clean, thus I just did
>
> ./autogen.sh 
> ./configure LDFLAGS="-fsanitize=address -fno-omit-frame-pointer"
> CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer"

Looks good.

> and `make' which printed, inter alia,

> ld: warning: dylib
>   (/usr/local/Cellar/little-cms2/2.13.1_1/lib/liblcms2.dylib) was
>   built for newer macOS version (12.0) than being linked (11.1)

AFAIK these warnings are annoying but harmless.

> 2022-09-13 10:48:30.934108-0400 emacs[18589:5791720] SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
> Process 18589 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)

That's not so good.  It means the address sanitizer couldn't catch
anything before Emacs crashed.

I'm afraid now it's going to get tedious, without some divine
inspiration.

>     frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
>    4017 {
>    4018   return pdumper_object_p (s)
>    4019     ? pdumper_marked_p (s)
> -> 4020     : s->u.s.gcmarkbit;
>    4021 }
>    4022
>    4023 static void
> Target 0: (emacs) stopped.

Hm, it's a fake Lisp symbol this time.  Last time it was a fake float.
Which fits the hypothesis of something writing "randomly" to the heap.  

Or it could be uninitialized memory, maybe.

> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)

>   * frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) at alloc.c:4020:14
>     frame #1: 0x00000001006db869 emacs`process_mark_stack(base_sp=0) at alloc.c:6943:10
>     frame #2: 0x00000001006d9a79 emacs`mark_object(obj=0x00007ff7bfee99d0) at alloc.c:7035:3
>     frame #3: 0x000000010052bf20 emacs`mark_kboards at
>     keyboard.c:13266:4

Last time there was also a mark_kboards on the stack.  I wonder if
that tells us something.

> what do I do next?

Good question ;-).

Could you please check the following:

- Does it also crash when you run emacs on a terminal (-nw)?  If not, it
  could be a hint that the cuöprit is in the NS GUI code.

- Could you please see if it crashes consistently in different runs?
  What I mean is that is crashes in the same function with the same
  backtrace and the same pointer value of the symbol in frame#0?  I
  guess I would quit LLDB between between runs, for no good reason
  :-), just to make sure it's reproducible that way.

- I think you mentioned that the crashes started not so long ago?  Do
  you perhaps know a commit which is still "good"?  Or maybe a time,
  like 4 weeks ago, or so?  We would need a good commit for git bisect
  anyway.

> Would you like to get on the phone to drive my fingers? ;-)

Hehe, that could only be helpful if I knew what I'm doing :-).

(If I'm trying the be too "helpful", please just tekk ne.  I Know that
I'm sometimes doing that.  No problem.)