GNU bug report logs -
#76970
31.0.50; master emacs crash with stack overflow
Previous Next
Reported by: Eval Exec <execvy <at> gmail.com>
Date: Wed, 12 Mar 2025 02:45:02 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Full log
View this message in rfc822 format
> Cc: app-emacs-dev <at> janestreet.com
> 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" <bug-gnu-emacs <at> gnu.org>
>
> 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?
This bug report was last modified 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.