From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Clemente <n142857@gmail.com>
Cc: 71473@debbugs.gnu.org
Subject: bug#71473: 30.0.50; crash in restore_kboard_configuration after pop_kboard
Date: Mon, 10 Jun 2024 22:29:15 +0300 [thread overview]
Message-ID: <86wmmw7g1g.fsf@gnu.org> (raw)
In-Reply-To: <CAJKAhPDmDnrmbpy4nL2j8ZjBjxYDRgDkUvFXVoSgz7xEQs7t4g@mail.gmail.com> (message from Daniel Clemente on Mon, 10 Jun 2024 16:05:29 +0000)
tags 71473 wontfix
thanks
> From: Daniel Clemente <n142857@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.
next prev parent reply other threads:[~2024-06-10 19:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 16:05 bug#71473: 30.0.50; crash in restore_kboard_configuration after pop_kboard Daniel Clemente
2024-06-10 19:29 ` Eli Zaretskii [this message]
2024-06-11 16:52 ` Daniel Clemente
2024-06-11 19:22 ` Eli Zaretskii
2024-06-11 20:00 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86wmmw7g1g.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=71473@debbugs.gnu.org \
--cc=n142857@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).