bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Eli Zaretskii]

> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
> Date: Thu, 12 Mar 2020 19:13:10 +0100
> Cc: 39962@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> 
> > My guess is 0x7ffeef270000 is your stack's guard page... Can you print
> > $rsp to confirm?
> 
> Sorry, because of the erratic behaviour of GDB I killed that one. I have a 
> new segfault in the GC. It is a long stack trace, so it could be a stack 
> overflow. And, by the way, I had the two brakpoints set for the assignments 
> to marker->charpos that Eli suggested, but they were not triggered. I have 
> dumped a part of the stack trace below.
> 
> Thread 3 received signal SIGSEGV, Segmentation fault.
> dead_object () at ./lisp.h:1303
> 1303    return make_lisp_ptr (NULL, Lisp_String);
> (gdb) bt
> #0  dead_object () at ./lisp.h:1303
> #1  0x00000001002b6179 in deadp (x=XIL(0x11e331fb5)) at alloc.c:433
> #2  0x00000001002b80d4 in live_cons_holding (m=0x16033ead0, p=0x170c5c770)
>     at alloc.c:4365

That does look like a stack overflow, since there's nothing at line
1303 of lisp.h which could cause a segfault, except a function call
(which pushes stuff onto the stack).  It doesn't seem to be related to
the crashes due to markers (unless those were somehow caused by  stack
overflow).

Can you enlarge the run-time stack size of the Emacs binary, e.g., by
using ulimit?  We may need to do that by default in the build command,
but just to check it is effective, could you run for a while with an
enlarged stack and see if crashes in GC go away?

Thanks.