Subject: bug#76970: 31.0.50; master emacs crash with stack overflow

From: Eli Zaretskii <[email-masked]>
Date: Wed, 12 Mar 2025 15:56:00 +0200

> From: Eval Exec <[email-masked]>
> Date: Wed, 12 Mar 2025 10:43:59 +0800
> 
> 
> Hello, I got a master branch emacs crash:
> 
> (gdb) bt full
> #0  0x000000000055979e in stack_overflow (siginfo=0x85d1b0 <sigsegv_stack+62640>) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1895
>         addr = 0x70 <error: Cannot access memory at address 0x70>
>         bot = <optimized out>
>         top = <optimized out>
>         LG_STACK_HEURISTIC = LG_STACK_HEURISTIC
> #1  handle_sigsegv (sig=11, siginfo=0x85d1b0 <sigsegv_stack+62640>, arg=<optimized out>) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1930
>         fatal = false
> #2  <signal handler called>
> No symbol table info available.
> #3  backtrace_top () at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:174
>         pdl = <optimized out>
>         pdl = <optimized out>
> #4  backtrace_top_function () at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:4270
>         pdl = <optimized out>
>         pdl = <optimized out>
> #5  add_sample (count=1, plog=<optimized out>) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/profiler.c:328
> No locals.
> #6  handle_profiler_signal (signal=27) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/profiler.c:380
>         count = 1
>         count = <optimized out>
>         overruns = <optimized out>
> #7  deliver_process_signal (handler=<optimized out>, sig=27) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1751
>         old_errno = 1
>         on_main_thread = true
>         old_errno = <optimized out>
>         on_main_thread = <optimized out>
>         blocked = <optimized out>
> #8  deliver_profiler_signal (signal=27) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/profiler.c:386
> No locals.
> Backtrace stopped: Cannot access memory at address 0x7ffe5c5f2678
> You can't do that without a process to debug.
> (gdb)

Is this the main thread ("thread 1"), or some other thread?  What does
"info threads" say?

Would it be possible for you to run Emacs under GDB at all times?
That would allow to do more when Emacs crashes, because some things
GDB cannot do when all it has is the core file, as opposed to a live
process.  E.g., the above backtrace doesn't give a clue what caused
stack overflow, because it shows too few stack frames.

Any idea what Emacs was doing when this happened?