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#61514: 30.0.50; sadistically long xml line hangs emacs Date: Sun, 19 Feb 2023 08:42:22 +0200 Message-ID: <83h6vixik1.fsf@gnu.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14410"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mah@everybody.org, 61514@debbugs.gnu.org To: Gregory Heytings , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 19 07:43:27 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 1pTdPz-0003aX-0s for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Feb 2023 07:43:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pTdPc-00020d-Ip; Sun, 19 Feb 2023 01:43: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 1pTdPa-00020N-Ex for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 01:43: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 1pTdPa-0007Pf-5k for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 01:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pTdPZ-0000ze-MI for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 01:43: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: Sun, 19 Feb 2023 06:43: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.16767889463771 (code B ref 61514); Sun, 19 Feb 2023 06:43:01 +0000 Original-Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 06:42:26 +0000 Original-Received: from localhost ([127.0.0.1]:45510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTdP0-0000yl-EB for submit@debbugs.gnu.org; Sun, 19 Feb 2023 01:42:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTdOy-0000yV-8t for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 01:42:24 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTdOs-0007N9-NG; Sun, 19 Feb 2023 01:42:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CBRGYT7VzLJCy6YrsPAabo1XCE2E0g0BMoQm2y7Ffuk=; b=QokBOD70Bv43 wpyD2ZyyebhHwMRwdLWHUKt3MfIz18bFbsCPoluQzb1cbwkdS+7rOV8dT01wo9L204lb1yrMcGfK0 J23Z3UpWKRZo3xQDFFpHMI93ZHPdvnv2Vqfa1GfEsgdxj/v5YEEHlI0kEFEnFALYWRQkdQavBQwEo X7iJaXdO4SYUn4U01SDrU3OBnG+K2JXFoCE27p1VaTsu0C9dqU/FjJYEb7uFaIKLyYXFRjD0bx4hr qeg9+q48bGCJvFsfAP9NizVC4OtE8i60Z/zbEghQusLgasUKTJh+ef4qPNpw+EcIixA65QXkopvrq FRBIuXxAl2yooXcBFEKTuA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTdOr-0007wQ-Bg; Sun, 19 Feb 2023 01:42:18 -0500 In-Reply-To: <886c06e50e9cfacb7954@heytings.org> (message from Gregory Heytings on Sun, 19 Feb 2023 00:46:05 +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:256029 Archived-At: > Date: Sun, 19 Feb 2023 00:46:05 +0000 > From: Gregory Heytings > cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org > > > Interestingly, the following simple patch fixes both the original and > > the truncated cases: > > > > diff --git a/src/regex-emacs.c b/src/regex-emacs.c > > index 2dca0d16ad9..eb943df46f0 100644 > > --- a/src/regex-emacs.c > > +++ b/src/regex-emacs.c > > @@ -877,7 +877,7 @@ #define INIT_FAILURE_ALLOC 20 > > whose default stack limit is 2mb. In order for a larger > > value to work reliably, you have to try to make it accord > > with the process stack limit. */ > > -ptrdiff_t emacs_re_max_failures = 40000; > > +ptrdiff_t emacs_re_max_failures = 37499; > > > > union fail_stack_elt > > { > > > > After some further investigation, that's probably not TRT to do here. > With a file truncated to 100000 characters, the same bug happens with > emacs_re_max_failures >= 15000, and disappears with emacs_re_max_failures > <= 14999. Hmmm... I'm not surprised. There's something weird going on there. Do you understand the logic in this snippet near the end of re_match_2_internal: /* We goto here if a matching operation fails. */ fail: maybe_quit (); if (!FAIL_STACK_EMPTY ()) { [...] } else break; /* Matching at this starting point really fails. */ } /* for (;;) */ if (best_regs_set) goto restore_best_regs; unbind_to (count, Qnil); SAFE_FREE (); if (max_redisplay_ticks > 0 && nchars > 0) update_redisplay_ticks (nchars / 50 + 1, NULL); return -1; /* Failure to match. */ What is the mechanism to empty the failure stack, which eventually causes us to report a failure? What I see is that the stack is either not being emptied, or being emptied very slowly. Do the "magic" numbers you came up with explain that? Maybe we should devise some mechanism whereby re_match_2_internal forcibly returns a failure after too much bactracking (if that is what happens here), when called from redisplay? Stefan, any ideas?