Stackoverflow in regexp matcher

Stackoverflow in regexp matcher

[Loris Bennett]

Hi,

On refreshing the #+TAGS via 'C-c C-c' I'm am getting the following error

Stackoverflow in regexp matcher

I have tried bisecting the file, but the problem does not seem to be
caused by a specific part.  Instead it just seems to occur at a fairly
random point once the file becomes long enough.

The file is a beamer presentation with 1375 lines.  If I add

* 0123456789

to the end of the file (or insert it at some other point), I can still
refresh.  If I add

* 0123456789
0

I get "Stackoverflow in regexp matcher".

Does anyone have any ideas how to proceed here?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Stackoverflow in regexp matcher

[Nick Dokos]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

> Hi,
>
> On refreshing the #+TAGS via 'C-c C-c' I'm am getting the following error
>
> Stackoverflow in regexp matcher
>

Not "Stack overflow in ..."? I searched for Stackoverflow both in the
org-mode directory and the emacs source directory (but I'm not up to
date with either so I might have missed a recent change): I didn't find
anything.

I found the similar

./src/search.c:  error ("Stack overflow in regexp matcher");

> I have tried bisecting the file, but the problem does not seem to be
> caused by a specific part.  Instead it just seems to occur at a fairly
> random point once the file becomes long enough.
>
> The file is a beamer presentation with 1375 lines.  If I add
>
> * 0123456789
>
> to the end of the file (or insert it at some other point), I can still
> refresh.  If I add
>
> * 0123456789
> 0
>
> I get "Stackoverflow in regexp matcher".
>
> Does anyone have any ideas how to proceed here?
>

M-x toggle-debug-on-error RET

try to reproduce and send the backtrace (if any).

--
Nick

Re: Stackoverflow in regexp matcher

[Loris Bennett]

Hi Nick,

Nick Dokos <ndokos@gmail.com> writes:

> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>> Hi,
>>
>> On refreshing the #+TAGS via 'C-c C-c' I'm am getting the following error
>>
>> Stackoverflow in regexp matcher
>>
>
> Not "Stack overflow in ..."? I searched for Stackoverflow both in the
> org-mode directory and the emacs source directory (but I'm not up to
> date with either so I might have missed a recent change): I didn't find
> anything.

Sorry, "Stack overflow".

> I found the similar
>
> ./src/search.c:  error ("Stack overflow in regexp matcher");
>
>> I have tried bisecting the file, but the problem does not seem to be
>> caused by a specific part.  Instead it just seems to occur at a fairly
>> random point once the file becomes long enough.
>>
>> The file is a beamer presentation with 1375 lines.  If I add
>>
>> * 0123456789
>>
>> to the end of the file (or insert it at some other point), I can still
>> refresh.  If I add
>>
>> * 0123456789
>> 0
>>
>> I get "Stackoverflow in regexp matcher".
>>
>> Does anyone have any ideas how to proceed here?
>>
>
> M-x toggle-debug-on-error RET
>
> try to reproduce and send the backtrace (if any).

I got the following error when I opened the file this morning:

File mode specification error: (error "Stack overflow in regexp matcher")

I then toggled debugging and did 'C-c C-c' on the #+TAGS line and got
the following backtrace:

Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
  re-search-forward("^[^%]*\\\\usepackage.*{biblatex}" nil t)
  reftex-using-biblatex-p()
  reftex-locate-bibliography-files("/home/loris/git/doc.git/")
  byte-code("\306\b\307	#\211\204\0\310\b!\211\203\0\311\v!\n\204%\312\bD\fB\313\314\315\"\210\212\316\317\b\"\210\320\n\321=?\"\211@q\210\311 \322\bD\fB\323 A\324\216\325B!\210\315C\212\214~\210\326b\210\327D\315\321#\203\272\326\225\203\260\x0eE\203\242\330\331!\331\332O\333\230\204\242\334\335!\203\236\334\336!\203\236\337 F\340\216\335 *E\235\206\232\337 F\341\216\336 *E\235?\202\237\321\203U\342\330\326!\bG#\fB\202U\343\225\203\376\331\224G`Sf\344=\203\304\345u\210H\b!\211I\203U\346I8JKJ^KJKU\203\362\316\347\350JL\"@\351I8#\210I\fB\x0eIM\202U\332\225\203\x01\330\332!N\352\315\353\354O\"\"\204U\355N\f	#\202U\356\225\2030\357\315\321\"\210\360\321B\fB\202U\361\225\203f\x0eP\203U\362\b!\211Q\203U\x0eQA@\211RS\235\203V\x0eS\210\202]\x0eRSBS)Q\fB\202U\363\225\203\263\212\330\363!T\363\225b\210\337 F\364\216\365\366T!!*U\367TV\"A@\211W\203\231\331\225b\210\202\240\363\225b\210\370 \210\342U\bG\315\211%\211X\fB-\202U\371\372!\210\202U\373	!\211Y\203\312\374YB\fB\326b\210\327\375\315\321#\203\333\376\bB\fB\326b\210\327\377\315\321#\203\370\201Z\330\201[!\330\343!E\fB\202\336\201\\\bD\fB.\201]\x0e@!\207" [file master-dir file-found buf docstruct reftex-keep-temporary-buffers reftex-locate-file "tex" reftex-get-buffer-visiting buffer-file-name file-error throw exit nil message "Scanning file %s" reftex-get-file-buffer-force t bof syntax-table ((set-syntax-table saved-syntax)) set-syntax-table 1 re-search-forward reftex-match-string 0 7 "label{" fboundp TeX-current-macro LaTeX-current-environment match-data ((byte-code "\301\b\302\"\207" [save-match-data-internal set-match-data evaporate] 3)) ((byte-code "\301\b\302\"\207" [save-match-data-internal set-match-data evaporate] 3)) reftex-label-info 3 92 -1 5 "Scanning %s %s ..." rassoc 6 delq mapcar #[(x) "\302\b	\"\207" [x include-file string-match] 3] reftex-parse-from-file 9 reftex-init-section-numbers appendix 10 ...] 7)
  reftex-parse-from-file("/home/loris/git/doc.git/hpc-workshop.org" nil "/home/loris/git/doc.git/")
  reftex-do-parse(1 nil)
  reftex-access-scan-info((16))
  reftex-parse-all()
  (and (buffer-file-name) (file-exists-p (buffer-file-name)) (setq TeX-master t) (reftex-parse-all))
  org-mode-reftex-setup()
  run-hooks(change-major-mode-after-body-hook text-mode-hook outline-mode-hook org-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook text-mode-hook outline-mode-hook org-mode-hook))
  run-mode-hooks(org-mode-hook)
  org-mode()
  org-mode-restart()
  org-ctrl-c-ctrl-c(nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
  command-execute(org-ctrl-c-ctrl-c)

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Stackoverflow in regexp matcher

[Nicolas Goaziou]

Hello,

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

>   re-search-forward("^[^%]*\\\\usepackage.*{biblatex}" nil t)

This is a pathological regexp. [^%] is anything but a percent sign, so
it can contain newline characters. Basically [^%]* can match an entire
buffer if it doesn't contain any %.

I think the regexp used in `reftex-using-biblatex-p' should be

  "^[^%\n]*\\\\usepackage.*{biblatex}"


Regards,

-- 
Nicolas Goaziou

Re: Stackoverflow in regexp matcher

[Loris Bennett]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>>   re-search-forward("^[^%]*\\\\usepackage.*{biblatex}" nil t)
>
> This is a pathological regexp. [^%] is anything but a percent sign, so
> it can contain newline characters. Basically [^%]* can match an entire
> buffer if it doesn't contain any %.
>
> I think the regexp used in `reftex-using-biblatex-p' should be
>
>   "^[^%\n]*\\\\usepackage.*{biblatex}"
>
>
> Regards,

So should this be filed as a bug against Emacs?

In the meantime, aside from patching my own Emacs, would there be any
other workaround, particularly considering that I don't currently need
any biblatex functionality.

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Stackoverflow in regexp matcher

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

On 2016-02-03 12:34, "Loris Bennett" <loris.bennett@fu-berlin.de> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Hello,
>>
>> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>>
>>>   re-search-forward("^[^%]*\\\\usepackage.*{biblatex}" nil t)
>>
>> This is a pathological regexp. [^%] is anything but a percent sign, so
>> it can contain newline characters. Basically [^%]* can match an entire
>> buffer if it doesn't contain any %.
>>
>> I think the regexp used in `reftex-using-biblatex-p' should be
>>
>>   "^[^%\n]*\\\\usepackage.*{biblatex}"
>>
>>
>> Regards,
>
> So should this be filed as a bug against Emacs?
>
> In the meantime, aside from patching my own Emacs, would there be any
> other workaround, particularly considering that I don't currently need
> any biblatex functionality.

This is a known bug:
http://comments.gmane.org/gmane.emacs.auctex.devel/3692

This thread also suggests a fix:

#+begin_src emacs-lisp
(with-eval-after-load 'reftex-parse
  (defun reftex-using-biblatex-p ()
    "Return non-nil if we are using biblatex rather than bibtex."
    (if (boundp 'TeX-active-styles)
	;; the sophisticated AUCTeX way
	(member "biblatex" TeX-active-styles)
      ;; poor-man's check...
      (save-excursion
	(re-search-forward "^[^%\n]*?\\\\usepackage.*{biblatex}" nil t)))))
#+end_src

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated February 1, 2016, Mauna Loa Obs.): 402.43 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Stackoverflow in regexp matcher

[Loris Bennett]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2016-02-03 12:34, "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>> Hello,
>>>
>>> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>>>
>>>>   re-search-forward("^[^%]*\\\\usepackage.*{biblatex}" nil t)
>>>
>>> This is a pathological regexp. [^%] is anything but a percent sign, so
>>> it can contain newline characters. Basically [^%]* can match an entire
>>> buffer if it doesn't contain any %.
>>>
>>> I think the regexp used in `reftex-using-biblatex-p' should be
>>>
>>>   "^[^%\n]*\\\\usepackage.*{biblatex}"
>>>
>>>
>>> Regards,
>>
>> So should this be filed as a bug against Emacs?
>>
>> In the meantime, aside from patching my own Emacs, would there be any
>> other workaround, particularly considering that I don't currently need
>> any biblatex functionality.
>
> This is a known bug:
> http://comments.gmane.org/gmane.emacs.auctex.devel/3692
>
> This thread also suggests a fix:
>
> #+begin_src emacs-lisp
> (with-eval-after-load 'reftex-parse
>   (defun reftex-using-biblatex-p ()
>     "Return non-nil if we are using biblatex rather than bibtex."
>     (if (boundp 'TeX-active-styles)
> 	;; the sophisticated AUCTeX way
> 	(member "biblatex" TeX-active-styles)
>       ;; poor-man's check...
>       (save-excursion
> 	(re-search-forward "^[^%\n]*?\\\\usepackage.*{biblatex}" nil t)))))
> #+end_src
>
> Best,
>
> Alan

Thanks for the fix.

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Stackoverflow in regexp matcher

[Peter Neilson]

On Wed, 03 Feb 2016 06:19:43 -0500, Nicolas Goaziou  
<mail@nicolasgoaziou.fr> wrote:

> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>>   re-search-forward("^[^%]*\\\\usepackage.*{biblatex}" nil t)
>
> This is a pathological regexp. [^%] is anything but a percent sign, so
> it can contain newline characters. Basically [^%]* can match an entire
> buffer if it doesn't contain any %.
>
> I think the regexp used in `reftex-using-biblatex-p' should be
>
>   "^[^%\n]*\\\\usepackage.*{biblatex}"

Here's a link about the extreme difficulty of detecting pathological  
regular expressions:

https://mail.python.org/pipermail/python-dev/2003-May/035916.html

The author analyses the exponential not-found situation for (x+x+)+y and  
then suggests that for larger expressions, "... no more than 1 programmer  
in 1000 has even a vague idea how to start looking for such problems."