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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 21 Jun 2025 12:06:00 +0300

> Cc: [email-masked]
> Date: Tue, 17 Jun 2025 18:38:26 -0400
> From:  Aaron Zeng via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> I'd like to report that users at my site have seen this crash occur
> quite a few times recently, although not necessarily ending in a
> stack_overflow() frame (instead usually ending in backtrace_top()).
> 
> For us, we believe the incidence was increased by enabling
> global-diff-hl-mode (with diff-hl-update-async set to t, so that it
> uses threads).  If the Lisp profiler is running and SIGPROF happens to
> be delivered while current_thread is NULL, then the following code in
> backtrace_top will cause a segfault:
> 
>     union specbinding *
>     backtrace_top (void)
>     {
>       /* This is so "xbacktrace" doesn't crash in pdumped Emacs if they
>          invoke the command before init_eval_once_for_pdumper initializes
>          specpdl machinery.  See also backtrace_p above.  */
>       if (!specpdl)                 /* HERE!!! */
>         return NULL;
> 
> add_sample (profiler.c) is called from a signal handler and therefore
> needs to be robust in the case where a thread has just died and there
> is no current thread, so it cannot blindly read specpdl.

Thanks, I installed a fix on the master branch, please see if it fixes
your problem.

> Here is a full backtrace that I managed to reproduce once.  Emacs was
> built at commit 31bac0d68c08f3f2fb03fa6ded17b771b168353e.
> Unfortunately, getting a completely reliable reproduction has proved
> tricky.
> 
> emacs -Q
> M-x package-initialize
> M-: (setopt diff-hl-update-async t)
> M-x global-diff-hl-mode
> ... and then visiting some files under version control
> 
> (gdb) bt full
> #0  0x00000000005564f7 in stack_overflow (siginfo=0xcbeb30 <sigsegv_stack+62896>) at sysdep.c:1902
>         addr = 0x70 <error: Cannot access memory at address 0x70>
>         bot = <optimized out>
>         top = <optimized out>
>         fatal = false
> #1  0x00000000005564f7 in handle_sigsegv (sig=11, siginfo=0xcbeb30 <sigsegv_stack+62896>, arg=<optimized out>) at sysdep.c:1937
>         fatal = false
> #2  0x00007fbda4812970 in <signal handler called> () at /lib64/libpthread.so.0
> #3  0x00000000005c3f27 in backtrace_top () at eval.c:4294
>         pdl = <optimized out>
>         pdl = <optimized out>
> #4  0x00000000005c3f27 in backtrace_top_function () at eval.c:4294
>         pdl = <optimized out>
> #5  0x000000000063a0da in add_sample (plog=0xcdf060 <cpu>, count=1436) at lisp.h:1192
> #6  0x0000000000557604 in deliver_process_signal (sig=27, handler=0x63a440 <handle_profiler_signal>) at sysdep.c:1758
>         old_errno = 11
>         on_main_thread = true
> #7  0x00007fbda4812970 in <signal handler called> () at /lib64/libpthread.so.0
> #8  0x00007fbda481154a in __lll_unlock_wake () at /lib64/libpthread.so.0
> #9  0x00007fbda480c2e6 in __pthread_mutex_unlock_usercnt () at /lib64/libpthread.so.0
> #10 0x000000000063af2f in release_global_lock () at thread.c:621
>         sa = 0x7ffc6645abd0
>         self = 0xc76300 <main_thread>
>         oldset = {__val = {0, 0, 843691369, 843691368, 843691369, 843691368, 0, 837799220, 0, 1, 13385680, 13385744, 0, 0, 13385680, 13385744}}
> #11 0x000000000063af2f in really_call_select (arg=0x7ffc6645abd0) at thread.c:621
>         sa = 0x7ffc6645abd0
>         self = 0xc76300 <main_thread>
>         oldset = {__val = {0, 0, 843691369, 843691368, 843691369, 843691368, 0, 837799220, 0, 1, 13385680, 13385744, 0, 0, 13385680, 13385744}}

This seems to be a different problem?  The segfault is inside
release_global_lock, with self = current_thread = &main_thread, which
is not NULL?  Or what did I miss?