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

Previous Next

Full log

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

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

Hi Tassilo,

2015-12-13 17:55 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> David Kastrup <dak <at> gnu.org> writes:
>
>>>     (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 expression contains only a single explicit wildcard.  A stack
>> overflow for it most certainly is a bug.  Is this really fixed in 25.1
>> or is there just a larger stack?
>
> I also get a stack overflow with this starting with a buffer size of
> about 800 lines.  But I can run
>
>   (re-search-forward reftex-everything-regexp nil t)
>
> without problems even after adding 100.000 more "foo foo foo..." lines
> to the test file...

Uh, in Emacs 24.5

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

throws the stack overflow error, indeed I tested also this
possibility.  So are you saying that in Emacs 25.1 the noerror option
prevents stack overflow?  Anyway, how about my suggestion to use

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

?  1000 characters are 12.5 80-column-wide lines, I think it's large enough.

Bye,
Mosè

Previous Next

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