From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#61514: 30.0.50; sadistically long xml line hangs emacs Date: Sun, 19 Feb 2023 23:24:30 -0500 Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25945"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 20 05:25:22 2023 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 1pTxjt-0006Zz-Ae for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Feb 2023 05:25:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pTxjc-000584-Jr; Sun, 19 Feb 2023 23:25:04 -0500 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 1pTxja-00057r-Ez for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 23:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pTxja-0004Et-4l for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 23:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pTxjZ-0001zQ-Mo for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 23:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Feb 2023 04:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61514 X-GNU-PR-Package: emacs Original-Received: via spool by 61514-submit@debbugs.gnu.org id=B61514.16768670867624 (code B ref 61514); Mon, 20 Feb 2023 04:25:01 +0000 Original-Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 04:24:46 +0000 Original-Received: from localhost ([127.0.0.1]:50134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTxjK-0001yu-5k for submit@debbugs.gnu.org; Sun, 19 Feb 2023 23:24:46 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTxjI-0001yf-IK for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 23:24:45 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ADB39100099; Sun, 19 Feb 2023 23:24:38 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 337F6100048; Sun, 19 Feb 2023 23:24:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676867077; bh=GifiqU9wZHKzBQNkkqOezTLlOO1SyQaUB3G7+wuzwXw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NMAmXupkUVseGBOAtEV6G8Xklt6ShbeZSgEL1zqutZoAyNTTx7+2crM8oa/31eJ8P xosonoK0lxsm2BfGjVEcEZ13toYWtOwOBl4X84sbZuh4R50AGUcsNneLLktOzm2TEY J08ayeOCsetP5h5CC31PhdY0M4PZq2hmCZdkGQrz9fjwGNu3ZUv8BjxUe2caRzEMtj d+1AbeHS0xAK394omhhkPENzfw+/UWLg3LbZxa7NZ0Csffk6mAcfW19RL3/iptVpWF VWzJS108XOM2y0HTGFftU6oCU+7pGd/v/cL8vmKZsupWojhEadjFgK2CH9zgk9o7yY 0pFVKTbzGNnUA== Original-Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 016771231B3; Sun, 19 Feb 2023 23:24:36 -0500 (EST) In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 02:05:59 +0000") 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:256127 Archived-At: > Looking at the history of that variable, which is in fact a compile-time > constant, I see that it was initially (May 1995) set to 200000. A few > months later (Nov 1995) it was set to 20000, and reduced again (apparently > because of bug reports) to 8000 and to 4000 (both in Jun 1996). Two months > later it was again set to 20000 (Aug 1996), and a year later to 40000 (Dec > 1997). It kept that value since then. As these changes (and this bug > report) demonstrate, it is not possible to give that variable a "one size > fits all" value. Note that the stack is allocated with `SAFE_ALLOCA` and used to be allocated with just `alloca`. So the constant was probably reduced (back in the 90s) in response to reports of segfaults due to C stack overflows. Nowadays we should be hopefully(?) safe from such segfaults since `SAFE_ALLOCA` only uses `alloca` for smallish allocations. > @@ -731,7 +731,8 @@ xmltok-scan-after-comment-open > > (defun xmltok-scan-attributes () > (let ((recovering nil) > - (atts-needing-normalization nil)) > + (atts-needing-normalization nil) > + (regexp-max-failures 1000)) > (while (cond ((or (looking-at (xmltok-attribute regexp)) > ;; use non-greedy group > (when (looking-at (concat "[^<>\n]+?" This really needs a comment (at least one referring to this bug report). I think the idea is that we hope the regexp will need at most one stack entry per character, so the above means that we're willing to limit the regexp search to about 1kB of text, which sounds fair given it's supposed to match just a single XML attribute. > + DEFVAR_INT ("regexp-max-failures", Vregexp_max_failures, > + doc: /* Maximum number of failures points in a regexp search. */); > + Vregexp_max_failures = max_regexp_max_failures; This name is misleading. It suggests it's talking about how many times we fail, whereas the reality is that it's about the number of pending branches in the search space (which the source code calls "failure points" because it's info to be used in case the current branch fails to match). It could also be described as the number of "pending continuations" or "stacked failure continuations" or some wording like that. But for the var name itself, how 'bout `regexp-max-backtracking-depth`? Stefan