> From: Daniel Clemente <n142857@gmail.com>
> Date: Sun, 26 May 2024 10:58:41 +0000
> Cc: 71176@debbugs.gnu.org
>
> With only the 3rd patch you sent (i.e. having removed the 1st patch), it doesn't crash. Opening and closing
> frames works, and emacsclient is usable even after what I describe below.
> Normal usage seems also fine (defining "fine" as: I see another TTY-only bug but it's unrelated). Using it with
> my full ~/.emacs also works.
>
> However after around 1 minute of opening+killing frames with the bash for-loop I mentioned, the C stack is
> much higher (see first backtrace below).
> If I let it continue (~3 minutes in total), it leads to: Lisp nesting exceeds ‘max-lisp-eval-depth’: 1601. In "bt" I saw
> a stack of 21k function calls.
>
> Below the first "bt" I attach a fragment of "bt full" (from a different run).
> If just stay a few seconds opening+kill frames (not 1 minute), then stop, it doesn't have such a high stack (see
> bt tagged bt222 below).
>
> This may be a different bug; if you want I can report it separately.

I think it's indeed a different issue -- if it is an issue at all:
after all "Lisp nesting exceeds ‘max-lisp-eval-depth’" is not a crash,
just a Lisp error, and it follows a use pattern that is, let's say,
not very interesting.  What I see is that Emacs recursively calls
functions that read from a client process, which most probably is
called by the error recovery of server.el when you kill client frames.
The error recovery code includes some wait functions that are intended
to let the user see the error messages, and making that possible is
much more important for us than avoiding Lisp nesting in scenarios
like this one.

So yes, I think you should submit a separate issue with the details.

In any case, please report backtraces with a Lisp backtrace (GDB will
do that automatically if you invoke it from the src directory of
Emacs, or if you manually "source .gdbinit").  These deep backtraces
are very hard to read and interpret otherwise.