From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#58601: 29.0.50; Infinite loop in byte-compile--first-symbol-with-pos Date: Wed, 19 Oct 2022 08:52:10 +0000 Message-ID: References: <8735bm6nl9.fsf@tcd.ie> <87pmepw0ov.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39409"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 58601@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 19 10:53:33 2022 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 1ol4pR-0009zR-GM for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Oct 2022 10:53:33 +0200 Original-Received: from localhost ([::1]:55988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ol4pQ-0004qc-6Z for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Oct 2022 04:53:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32904) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ol4ox-0004pW-8P for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2022 04:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56692) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ol4ox-00053j-0c for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2022 04:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ol4ow-0001GE-7L for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2022 04:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2022 08:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58601 X-GNU-PR-Package: emacs Original-Received: via spool by 58601-submit@debbugs.gnu.org id=B58601.16661695404794 (code B ref 58601); Wed, 19 Oct 2022 08:53:02 +0000 Original-Received: (at 58601) by debbugs.gnu.org; 19 Oct 2022 08:52:20 +0000 Original-Received: from localhost ([127.0.0.1]:55770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ol4oG-0001FG-Cw for submit@debbugs.gnu.org; Wed, 19 Oct 2022 04:52:20 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:38681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ol4oE-0001F2-Jj for 58601@debbugs.gnu.org; Wed, 19 Oct 2022 04:52:19 -0400 Original-Received: (qmail 65513 invoked by uid 3782); 19 Oct 2022 10:52:11 +0200 Original-Received: from acm.muc.de (p4fe15a32.dip0.t-ipconnect.de [79.225.90.50]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 19 Oct 2022 10:52:10 +0200 Original-Received: (qmail 3434 invoked by uid 1000); 19 Oct 2022 08:52:10 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:245850 Archived-At: On Tue, Oct 18, 2022 at 15:19:35 -0400, Stefan Monnier wrote: > >> That's not the problem, because it's just for illustrative purposes. > >> Instead of 'arg' being passed unchanged as the FORM argument, it could > >> just as well have been `(my-frobnicate ,arg). > > That would not loop, since there is a symbol with position there. > BTE, the real-world use case is a compiler macro which takes the list of > args and tucks the name of another function in front. So the generated > code, passed to `macroexp-warn-and-return` has the shape > (somefun somearg1 somearg2) > where `somefun` does *not* come from the source but from the > compiler-macro instead and hence doesn't have any sympos, and then > `somearg1` was an expression of the form > (quote #1=(1 2 3 . #1#)) > So, there was no cycle in the code part, the cycle is only inside the > data embedded in the code. I think somebody who writes something like that _deserves_ to go into an infinite loop. Have you ever seen anything at all like this in real life? You have fixed this "problem" by arbitrarily limiting the size of valid form stacks that can be searched, and the depth to which they can be searched. This limit, 10, seems too small. There can easily be form stacks with more than 10 elements. Do you have any objection if I change that 10 to something closer to infinity? Something which will encompass any form stack likely to be encountered in practice? I would suggest the number 300. > Stefan -- Alan Mackenzie (Nuremberg, Germany).