GNU bug report logs - #77205
31.0.50; Emacs sometimes crashes if many frames are present

Previous Next

Full log

Message #8 received at 77205 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 77205 <at> debbugs.gnu.org
Subject: Re: bug#77205: 31.0.50;
 Emacs sometimes crashes if many frames are present
Date: Sun, 23 Mar 2025 13:25:09 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Date: Sun, 23 Mar 2025 11:47:08 +0100
> 
> To reproduce this issue, please download many_frames_tty.el from:
> 
>     https://www.metalevel.at/ei/many_frames_tty.el
> 
> Then start Emacs with:
> 
>     $ emacs -Q -nw --load many_frames_tty.el
> 
> Leave it running for a while, then press:
> 
>     C-g C-g
> 
> The expected result is that the loop is interrupted

No, that's not the expected result when you press C-g twice in qwuick
succession on a TTY frame.  That sequence invokes the "emergency
escape" procedure.

> and this works in many cases. However, in some cases, Emacs crashes
> with:
> 
>     lisp.h:1697: Emacs fatal error: assertion failed: 0 <= nbytes
> 
>     lisp.h:1697: Emacs fatal error: assertion failed: 0 <= nbytes
>     Aborted (core dumped)
> 
> and sometimes with:
> 
>     /lib/x86_64-linux-gnu/libc.so.6(+0x28150)[0x77e7df428150]
>     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x89)[0x77e7df428209]
>     ./emacs(+0x3f5c5)[0x602bae7015c5]
>     Aborted (core dumped)
> 
> This is related to #77200 in that Emacs also crashes, however the
> backtraces are now different, and the crash occurs after C-g C-g.
> 
> Please see below two different backtraces I got after such crashes.
> 
> Backtrace #1:
> ======================================================================
> 
> #0  0x00007ffff7442bcb in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
> #1  0x0000555555791a46 in sys_suspend () at sysdep.c:633
> #2  0x000055555577f720 in handle_interrupt (in_signal_handler=true) at keyboard.c:12287
> #3  0x000055555577f5a1 in handle_interrupt_signal (sig=2) at keyboard.c:12213
> #4  0x0000555555793556 in deliver_process_signal (sig=2, handler=0x55555577f548 <handle_interrupt_signal>) at sysdep.c:1751
> #5  0x000055555577f5c7 in deliver_interrupt_signal (sig=2) at keyboard.c:12220
> #6  <signal handler called>

AFAIU, this backtrace is not relevant: it simply means that Emacs was
stopped by SIGTSTP, and GDB kicked in.

> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:424
> #1  0x000055555581157a in die (msg=0x55555597305d "0 <= nbytes", file=0x555555972fc8 "lisp.h", line=1697) at alloc.c:7452
> #2  0x00005555556d20a6 in STRING_BYTES (s=0x555555bb6b20) at /emacs/src/lisp.h:1697
> #3  0x00005555556d20cc in SBYTES (string=XIL(0x555555bb6b24)) at /emacs/src/lisp.h:1704
> #4  0x00005555556d3087 in tty_send_additional_strings (terminal=0x555555b57180, sym=XIL(0x12900)) at term.c:187
> #5  0x00005555556d3453 in tty_reset_terminal_modes (terminal=0x555555b57180) at term.c:230
> #6  0x0000555555792ff4 in reset_sys_modes (tty_out=0x555555b60e40) at sysdep.c:1535

This one happens because we are accessing Lisp strings in the middle
of GC.  I installed a fix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.