From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Clemente Newsgroups: gmane.emacs.bugs Subject: bug#71176: 30.0.50; Segmentation fault (SIGSEGV) in TTY+emacsclient, default_face is nil Date: Mon, 27 May 2024 11:05:53 +0000 Message-ID: References: <86r0dr106n.fsf@gnu.org> <867cfiyset.fsf@gnu.org> <86r0dpyfa8.fsf@gnu.org> <86plt9ye94.fsf@gnu.org> <86o78tyddh.fsf@gnu.org> <864jakwj8j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c4582806196d8127" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17148"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71176@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 27 13:07:58 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sBYCs-0004Ft-1C for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 May 2024 13:07:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBYCp-00036D-CX; Mon, 27 May 2024 07:07:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBYCn-00035t-Sn for bug-gnu-emacs@gnu.org; Mon, 27 May 2024 07:07:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sBYCn-0004rE-KZ for bug-gnu-emacs@gnu.org; Mon, 27 May 2024 07:07:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sBYCw-0000S7-8f for bug-gnu-emacs@gnu.org; Mon, 27 May 2024 07:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Clemente Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 May 2024 11:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71176 X-GNU-PR-Package: emacs Original-Received: via spool by 71176-submit@debbugs.gnu.org id=B71176.17168080551707 (code B ref 71176); Mon, 27 May 2024 11:08:02 +0000 Original-Received: (at 71176) by debbugs.gnu.org; 27 May 2024 11:07:35 +0000 Original-Received: from localhost ([127.0.0.1]:43175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBYCV-0000RT-0u for submit@debbugs.gnu.org; Mon, 27 May 2024 07:07:35 -0400 Original-Received: from mail-ot1-f45.google.com ([209.85.210.45]:44078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBYCT-0000RH-NG for 71176@debbugs.gnu.org; Mon, 27 May 2024 07:07:34 -0400 Original-Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-6f8e26f226dso845515a34.0 for <71176@debbugs.gnu.org>; Mon, 27 May 2024 04:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716807979; x=1717412779; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xdCl/p+JTHuOJdnC0KtAWiSq+hHnbvyjy3g9DltCc6Q=; b=SFn+bUwvVYmDoseHsib1FQIf9bE8eYBnAgJbrh31e7mWdl8ZosxczZfleHRThXjbrb cgb2FX4JNrwd5ZZRx0mu1jV4+36dN8Fi8CY2U9PuT3sqqlilXD34rvzVG7DH/zxvAJKA FeztLMtoXJ//310BFx4Zkydnu5ZyxgKpI2aetcEByAvDfYBbv86oOZtGOxQOnw31T2kV XePN8ZzCYHRXKQiAXbgw+JwwT5h6Ipt6C1Vdc3x/qkOuXlgJ6GaysVUWW/cADSWaW2Qm a1Fsh9j3qhO9DJ45PG95UBn/NaS0V6ulSbbgM2rl5Zl+kXajqL6m1amqFbAbQkB0QNNS +Xaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716807979; x=1717412779; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xdCl/p+JTHuOJdnC0KtAWiSq+hHnbvyjy3g9DltCc6Q=; b=mFEuxkf85SoU/g87dL/6SOIOrOXjUKB7QHdVK9SyS7rSCNLYUSTu4ptyra8qcGYcbe jNxiyLr9uQpW3PdYF4yGMkWlSa4v2dE3nJOV08ew8XCM5xPh6/Dwf0sDwtPP26BHCqjt ed9K1i9rRKHXCmyP/32zh+rDx6we4xPsOxdeOtHez/QdIwXifssKvEu0+NGxRtZj77ff BkuxDjgYJ5Qqbay6oux3+IEKVUQ83GeoJv1z3jFw5XNpT/0mDxUF3YNvLnYMtFj9bcQm WSnfdJl1bTNWsVASDJgUdfMEFFet4YjVvPRKgRwYjn8wyx2lbDOpnXAynChuISDogpMi 80YQ== X-Gm-Message-State: AOJu0YwcW8wCrpUb0r2nGV11gmFb6kZbIvFz7TvoyRNUddWxz34MQOuL 7/dZuOwwkNMt0sDNEu2afah4EtVT38QkvMJjYcYreI8kiztvsLzTZxGYGXDDCBkIXt1VgwFJG7l hXffI48XFf4neYo8yo9f1nQzEj+HI52Jh X-Google-Smtp-Source: AGHT+IEBAsJ3VPv9zjLmJpgXaKK9B86IuAS4pKZDG2N40Io+NtcI6tnz2bbdEjO8xmTdhAezh5DOuq7O68Q9YC3U80M= X-Received: by 2002:a05:6830:1bd6:b0:6f0:7ca9:dd09 with SMTP id 46e09a7af769-6f8d0a80d68mr9689148a34.7.1716807979519; Mon, 27 May 2024 04:06:19 -0700 (PDT) In-Reply-To: <864jakwj8j.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286017 Archived-At: --000000000000c4582806196d8127 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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 =E2=80=98max-lisp-eval-depth=E2=80=99" is= not a crash, > [=E2=80=A6] 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 wrote: > > From: Daniel Clemente > > 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), i= t > doesn't crash. Opening and closing > > frames works, and emacsclient is usable even after what I describe belo= w. > > Normal usage seems also fine (defining "fine" as: I see another TTY-onl= y > 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 =E2=80=98max-lisp-eval-depth=E2=80=99: 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 =E2=80=98max-lisp-eval-depth=E2=80=99" 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. > --000000000000c4582806196d8127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > 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 =E2=80=98max-lisp-eval-depth=E2= =80=99" is not a crash,
> [=E2=80=A6]

<= /div>
Ok, I submitted bug#71223
And a SIGSEGV I found while t= esting 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@d= ebbugs.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 bel= ow.
> Normal usage seems also fine (defining "fine" as: I see anot= her 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 =E2=80=98max-lisp-eval-depth=E2=80=99: 1601. In "bt" I sa= w
> a stack of 21k function calls.
>
> Below the first "bt" I attach a fragment of "bt full&qu= ot; (from a different run).
> If just stay a few seconds opening+kill frames (not 1 minute), then st= op, 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 =E2=80=98max-lisp-eval-depth=E2=80=99&= quot; is not a crash,
just a Lisp error, and it follows a use pattern that is, let's say,
not very interesting.=C2=A0 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").=C2=A0 These deep ba= cktraces
are very hard to read and interpret otherwise.
--000000000000c4582806196d8127--