bug#71224: 30.0.50; SIGSEGV in start_display

[Eli Zaretskii]

> 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?