bug#71176: 30.0.50; Segmentation fault (SIGSEGV) in TTY+emacsclient, default_face is nil

[Daniel Clemente <n142857@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

> > 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,
> […]

Ok, I submitted bug#71223
And a SIGSEGV I found while testing this, possibly related, bug#71224


On Sun, 26 May 2024 at 17:55, Eli Zaretskii <eliz@gnu.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 3269 bytes --]