From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Clemente <n142857@gmail.com>
Cc: 71224@debbugs.gnu.org
Subject: bug#71224: 30.0.50; SIGSEGV in start_display
Date: Mon, 10 Jun 2024 19:30:04 +0300 [thread overview]
Message-ID: <86bk4892wj.fsf@gnu.org> (raw)
In-Reply-To: <CAJKAhPBdc2Og+UsgoCVwK_AOKnewdF5P3aV86Mr-FJOz4zNVvg@mail.gmail.com> (message from Daniel Clemente on Mon, 10 Jun 2024 16:11:50 +0000)
> From: Daniel Clemente <n142857@gmail.com>
> Date: Mon, 10 Jun 2024 16:11:50 +0000
> Cc: 71224@debbugs.gnu.org
>
> > Thanks, I could reproduce this and installed a fix.
> >
> > The result of the fix is that the daemon doesn't crash; the last
> > client gets an error message and exits, but the terminal from which
> > the last client connection was attempted is left in messed up state.
> > The user will then need to reset the terminal somehow, e.g. with "tput
> > reset" or somesuch.
>
> It seems more crash-resistant now, thanks.
>
> Leaving the terminal in a bad state doesn't seem a huge problem, since
> Emacs is in a bad state too.
Emacs is well enough to allow you to exit it in an orderly fashion.
Which is enough when you brought it to its knees by infinite
recursion.
> In some cases it's possible to go back to the working frame, fix the
> Lisp stack (e.g. by pressing q in the debug window to make all the
> (recurse) calls finish), and then the new emacsclient connections will
> work.
Emacs is supposed to be able to overcome overflow if the C stack. But
in this case, the overflow is in the Lisp nesting, not in the C stack.
Try "M-x top-level RET" and see if it helps.
> While testing this, the daemon kept crashing but at other points so I
> filed separate bugs
> - (I can't know the bug ID yet, but it may be #71473 or greater): delete_frame
> - (I can't know the bug ID yet, but it may be #71474 or greater):
> restore_kboard_configuration
No need to mention other bugs here, that just increases confusion (of
which we have more than enough already).
> In addition, I saw the backtrace below, I think that even after your
> patch („Avoid crashes in half-baked emacsclient frames“). I'm not 100%
> sure which commit I was in, sorry. Is this situation still possible
> after your patch? I can try to reproduce the crash but I'm seeing much
> more often the previous 2 new bugs I mentioned.
I don't know if it's the same scenario. If you show the recipe, I
might be able to determine that. Is w->desired_matrix a NULL pointer
again?
next prev parent reply other threads:[~2024-06-10 16:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 11:03 bug#71224: 30.0.50; SIGSEGV in start_display Daniel Clemente
2024-05-27 12:16 ` Eli Zaretskii
2024-05-28 15:36 ` Daniel Clemente
2024-05-28 15:55 ` Eli Zaretskii
2024-05-28 16:49 ` Daniel Clemente
2024-05-28 18:16 ` Eli Zaretskii
2024-05-28 18:45 ` Daniel Clemente
2024-05-28 19:17 ` Eli Zaretskii
2024-05-29 5:56 ` Daniel Clemente
2024-05-29 16:35 ` Eli Zaretskii
2024-05-30 9:55 ` Daniel Clemente
2024-05-30 12:05 ` Eli Zaretskii
2024-06-07 16:08 ` Daniel Clemente
2024-06-07 19:46 ` Eli Zaretskii
[not found] ` <CAJKAhPBdc2Og+UsgoCVwK_AOKnewdF5P3aV86Mr-FJOz4zNVvg@mail.gmail.com>
2024-06-10 16:30 ` Eli Zaretskii [this message]
2024-06-12 13:47 ` Daniel Clemente
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=86bk4892wj.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=71224@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).