From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#46586: 26.3, 27.1.50; Emacs crash in a backtrace (core) dump (a long standing issue) Date: Thu, 18 Feb 2021 16:16:23 +0200 Message-ID: <83k0r55umg.fsf@gnu.org> References: <83im6q7ka2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26741"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46586@debbugs.gnu.org, Stefan Monnier To: =?UTF-8?Q?=E8=B7=AF=E5=AE=A2?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 18 15:21:02 2021 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 1lCkAw-0006rB-Kc for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Feb 2021 15:21:02 +0100 Original-Received: from localhost ([::1]:37324 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCkAu-0000bj-SL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Feb 2021 09:21:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCk74-0005nf-2f for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2021 09:17:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34925) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lCk73-0008P0-PK for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2021 09:17:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lCk73-0007hR-L1 for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2021 09:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Feb 2021 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46586 X-GNU-PR-Package: emacs Original-Received: via spool by 46586-submit@debbugs.gnu.org id=B46586.161365778029537 (code B ref 46586); Thu, 18 Feb 2021 14:17:01 +0000 Original-Received: (at 46586) by debbugs.gnu.org; 18 Feb 2021 14:16:20 +0000 Original-Received: from localhost ([127.0.0.1]:46471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCk6N-0007gL-PK for submit@debbugs.gnu.org; Thu, 18 Feb 2021 09:16:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCk6M-0007g8-Rv for 46586@debbugs.gnu.org; Thu, 18 Feb 2021 09:16:19 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42090) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCk6H-00081i-AX; Thu, 18 Feb 2021 09:16:13 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3706 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lCk6G-0005GG-LT; Thu, 18 Feb 2021 09:16:13 -0500 In-Reply-To: (message from =?UTF-8?Q?=E8=B7=AF=E5=AE=A2?= on Thu, 18 Feb 2021 09:56:06 +0800) 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" Xref: news.gmane.io gmane.emacs.bugs:200254 Archived-At: > From: 路客 > Date: Thu, 18 Feb 2021 09:56:06 +0800 > Cc: 46586@debbugs.gnu.org > > > It's an infinite recursion in substitute_object_recurse, called by > > lread--substitute-object-in-subtree. > > I see, but why is Emacs 26.0.50 or earlier able to catch this issue? The related code was refactored since then. (And I'm not sure Emacs 26.0.50 indeed identified the problem correctly, see below. So it could be just sheer luck that it didn't crash back then.) > Shouldn't the read() function try to prevent itself from crashing? It should, so this is a bug. But how did such a form get originated? It looks like it's indeed self-referential, and thus is got to trigger infinite recursion: > (#1=(#("000008964 .gnus.el" 0 18 (r #1#)) > (def #2=#("000008964 .gnus.el" 0 18 > (r > (#2# > (def #3=#("000006393 .gnus.el" 0 18 > (r #4=(#3# > (def > #("000006393 .gnus.el" 0 18 (r #4#)) "x"))))"x"))))"x"))) The last part references itself: it seems to define a string with a text property that is the same string. Stepping through the code in substitute_object_recurse, I see that we end up recursively expanding this string: #("000006393 .gnus.el" 0 18 (r (#("000006393 .gnus.el" 0 18 (r #2)) (def #0 "x")))) Which then yields this: #("000006393 .gnus.el" 0 18 (r (#0 (def #("000006393 .gnus.el" 0 18 (r #2)) "x")))) And that again yields #("000006393 .gnus.el" 0 18 (r (#("000006393 .gnus.el" 0 18 (r #2)) (def #0 "x")))) Etc. etc., ad nauseam (or, rather, until we exhaust the C run-time stack and segfault). Does anyone see how to stop this infinite recursion, except by counting recursive invocation levels and bailing out at some arbitrary depth?