GNU bug report logs - #61514
30.0.50; sadistically long xml line hangs emacs

Previous Next

Full log

Message #65 received at 61514 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Mark A. Hershberger" <mah <at> everybody.org>, 61514 <at> debbugs.gnu.org
Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Sat, 18 Feb 2023 23:06:10 +0000

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
 {

I obtained the magical 37499 value by bisecting.  Both cases fail with 
37500 (or higher), and work as expected (i.e. they fail with "Stack 
overflow in regexp matcher") with 37499.  I don't know why exactly, but I 
note that:

37499 * 8 = 299992 and 37500 * 8 = 300000 (where 8 is sizeof (fail_stack_elt_t))

37499 * 20 * 8 = 5999840 and 37500 * 20 * 8 = 6000000 (where 20 is TYPICAL_FAILURE_SIZE)

so it seems that there is a kind of limit at exactly 6000000 bytes?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.