GNU bug report logs - #22146
Stack overflow in reftex-parse-all

Previous Next

Full log

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

From: Mosè Giordano <mose <at> gnu.org>
To: David Kastrup <dak <at> gnu.org>
Cc: Nils Kanning <nils <at> kanning.de>, 22146 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#22146: Stack overflow in reftex-parse-all
Date: Sun, 13 Dec 2015 12:53:30 +0100

Hi David,

2015-12-12 11:05 GMT+01:00 David Kastrup <dak <at> gnu.org>:
> Mosè Giordano <mose <at> gnu.org> writes:
>
>> I'm not completely sure how to fix a "Stack overflow in regexp
>> matcher" error: the problem is that it matches nothing or too much?
>
> It has incomplete matches in too many different ways.  Something like
>
> .*.*
>
> is a trivial example of stuff that can usually match in too many
> different ways.  A nice regexp is one where each character of an
> incomplete match is only a candidate for a single component of the
> regexp.
>
> An ugly regexp is one where adding one character to the match grows the
> possibly match/pattern correspondences by more than one repeatedly.

Thanks for the explanation, but in this concrete case I can reproduce
the bug in Emacs 24.5 evaluating

    (re-search-forward "\\[[^]]*\\<label")

at the beginning of the buffer suggested by Nils.  So, it doesn't seem
there is an incomplete match, but simply "\\[[^]]*" is too greedy.
This also explains why closing the bracket works around the bug.

Tassilo, does `reftex-parse-all' fail with larger buffers in Emacs 25?
 If so, we can make the regexp less greedy by specifying the maximum
number of non-closing brackets characters, something like

    "\\[[^]]\{0,1000\}\\<label"

I don't know if this can somehow affect performances.

Bye,
Mosè

Previous Next

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