GNU bug report logs - #71473
30.0.50; crash in restore_kboard_configuration after pop_kboard

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Clemente <n142857 <at> gmail.com>
Cc: 71473 <at> debbugs.gnu.org
Subject: Re: bug#71473: 30.0.50;
 crash in restore_kboard_configuration after pop_kboard
Date: Mon, 10 Jun 2024 22:29:15 +0300

tags 71473 wontfix
thanks

> From: Daniel Clemente <n142857 <at> gmail.com>
> Date: Mon, 10 Jun 2024 16:05:29 +0000
> 
> This is a continuation of bug 71224 and it may be a similar issue.
> It's also similar to the last bug I just reported (see thisbugnumber-1)
> 
> I'm using Emacs without X support but running it in an X terminal.
> With glyph debug enabled. emacsclient, with -Q.
> 
> I was using the same reproduction procedure as in bug 71224. I was
> randomly mixing these actions:
> - automatically filling the Lisp stack by causing infinite recursion
> every 0.1 seconds, by launching the server like this:   emacs
> --fg-daemon -Q --eval '(progn (defun recurse () (recurse))
> (run-with-timer 0.1 0.1 (quote recurse)))'
> - call to (debug), once or twice, to open a backtrace window
> - opening new frames, just 2 or 3
> - closing a frame, just 1 or 2
> - moving the cursor a bit, normally
> 
> After a few seconds, this happens. This is of course a rare crash,
> since Emacs is in stress conditions. But debugging and consuming the
> Lisp stack shouldn't crash the server. Besides, I could reproduce this
> several times using the methods above and some luck.
> 
> I don't know whether a call to emacs_abort is considered a problem.
> 
> 
> Error running timer ‘recurse’: (excessive-lisp-nesting 1601)
> Error running timer ‘recurse’: (excessive-lisp-nesting 1601)
> Error running timer ‘recurse’: (excessive-lisp-nesting 1601)
> Error running timer ‘recurse’: (excessive-lisp-nesting 1601)
> 
> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:443
> 443      signal (sig, SIG_DFL);
> 
> (gdb) bt
> 
> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:443
> #1  0x00005555556bd46e in emacs_abort () at sysdep.c:2391
> #2  0x00005555556901b3 in restore_kboard_configuration (was_locked=1)
> at keyboard.c:960
> #3  0x0000555555772540 in do_one_unbind (this_binding=0x7fffffff8bd0,
> unwinding=true,
>     bindflag=SET_INTERNAL_UNBIND) at eval.c:3702
> #4  0x00005555557728e5 in unbind_to (count=..., value=XIL(0)) at eval.c:3834
> #5  0x000055555576be9a in unwind_to_catch (catch=0x55555605c950,
> type=NONLOCAL_EXIT_THROW, value=XIL(0))
>     at eval.c:1349
> #6  0x000055555576c002 in Fthrow (tag=XIL(0xfc90), value=XIL(0)) at eval.c:1378
> #7  0x0000555555690a5b in Ftop_level () at keyboard.c:1219
> #8  0x0000555555770a79 in funcall_subr (subr=0x555555eb81e0
> <Stop_level>, numargs=0, args=0x7fffffff8e10)
>     at eval.c:3159

Sorry, I'm going to drop the ball on this one.  You've somehow caused
Emacs to enter the debugger while in redisplay, which causes us to
throw to top-level.  I think it's okay for Emacs to commit suicide in
that case.

Previous Next

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