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

Previous Next

Package: auctex;

Reported by: Nils Kanning <nils <at> kanning.de>

Date: Fri, 11 Dec 2015 21:19:02 UTC

Severity: normal

Done: Tassilo Horn <tsdh <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #17 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
Subject: Re: bug#22146: Stack overflow in reftex-parse-all
Date: Sat, 12 Dec 2015 10:41:54 +0100
Hi Tassilo,

2015-12-12 8:54 GMT+01:00 Tassilo Horn <tsdh <at> gnu.org>:
> Mosè Giordano <mose <at> gnu.org> writes:
>
> Hi Nils & Mosé,
>
>>> In case you are wondering, the non-matching brackets [\} appear for
>>> example in physics as so-called "super Lie brackets".
>>
>> Thanks for taking the time to report this bug, I can reproduce it.
>
> I can reproduce it with Emacs 24.5 but not with Emacs 25.0.50.16 from
> the current emacs-25 branch.  So maybe it has been fixed after the last
> release (either the regex, or the Emacs regex matcher has become
> better).

`reftex-compile-variables' hasn't been changed in the last two years,
maybe Emacs regexp matcher has been improved.  But the error may
indicate of a malformed, or too greedy, regexp.

> If anyone of you could try with Emacs 25 and report back, that'd be
> great.
>
>> There is a simple workaround you can put in your code: close the
>> brackets, also in a comment is fine:
>>
>>     [\} % ]
>>
>> But I don't know how to really fix the bug, it's too late for me to
>> decrypt that regexp now.  Having a clue of what it should *exactly*
>> match would be of great help.
>
> Obviously, it should match everything that's interesting to reftex. :-)
>
> But seriously, have a look at the bottom of `reftex-compile-variables'
> where `reftex-everything-regexp' is composed from several other regexes
> with more local scopes, e.g., one for matching labels, one for sections,
> one for index entries, etc.

Yes, I saw it, but it was too late to really study it ;-)  I can see
there are some labeling and sectioning commands, but there are also
many groups matching something less intuitive at a first glance.  I'll
try to have a more thorough look in the next days.

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?
My understanding is the former, but the culprit could be the all those
\n\r, that cause the regexp to try and match all the buffer, even if
it fails in the end.

Bye,
Mosè




This bug report was last modified 9 years and 163 days ago.

Previous Next


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