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

Previous Next

Package: emacs;

Reported by: "Mark A. Hershberger" <mah <at> everybody.org>

Date: Tue, 14 Feb 2023 21:05:02 UTC

Severity: normal

Found in version 30.0.50

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


Message #68 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: Sun, 19 Feb 2023 00:46:05 +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
> {
>

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...





This bug report was last modified 2 years and 147 days ago.

Previous Next


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