* Stackoverflow in regexp matcher
@ 2016-02-02 13:56 Loris Bennett
2016-02-02 15:47 ` Nick Dokos
0 siblings, 1 reply; 8+ messages in thread
From: Loris Bennett @ 2016-02-02 13:56 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Stackoverflow in regexp matcher
2016-02-02 13:56 Stackoverflow in regexp matcher Loris Bennett
@ 2016-02-02 15:47 ` Nick Dokos
2016-02-03 7:36 ` Loris Bennett
0 siblings, 1 reply; 8+ messages in thread
From: Nick Dokos @ 2016-02-02 15:47 UTC (permalink / raw)
To: emacs-orgmode
"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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Stackoverflow in regexp matcher
2016-02-02 15:47 ` Nick Dokos
@ 2016-02-03 7:36 ` Loris Bennett
2016-02-03 11:19 ` Nicolas Goaziou
0 siblings, 1 reply; 8+ messages in thread
From: Loris Bennett @ 2016-02-03 7:36 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Stackoverflow in regexp matcher
2016-02-03 7:36 ` Loris Bennett
@ 2016-02-03 11:19 ` Nicolas Goaziou
2016-02-03 11:34 ` Loris Bennett
2016-02-03 11:44 ` Peter Neilson
0 siblings, 2 replies; 8+ messages in thread
From: Nicolas Goaziou @ 2016-02-03 11:19 UTC (permalink / raw)
To: Loris Bennett; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Stackoverflow in regexp matcher
2016-02-03 11:19 ` Nicolas Goaziou
@ 2016-02-03 11:34 ` Loris Bennett
2016-02-03 17:50 ` Alan Schmitt
2016-02-03 11:44 ` Peter Neilson
1 sibling, 1 reply; 8+ messages in thread
From: Loris Bennett @ 2016-02-03 11:34 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Stackoverflow in regexp matcher
2016-02-03 11:34 ` Loris Bennett
@ 2016-02-03 17:50 ` Alan Schmitt
2016-02-04 7:30 ` Loris Bennett
0 siblings, 1 reply; 8+ messages in thread
From: Alan Schmitt @ 2016-02-03 17:50 UTC (permalink / raw)
To: Loris Bennett; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Stackoverflow in regexp matcher
2016-02-03 17:50 ` Alan Schmitt
@ 2016-02-04 7:30 ` Loris Bennett
0 siblings, 0 replies; 8+ messages in thread
From: Loris Bennett @ 2016-02-04 7:30 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Stackoverflow in regexp matcher
2016-02-03 11:19 ` Nicolas Goaziou
2016-02-03 11:34 ` Loris Bennett
@ 2016-02-03 11:44 ` Peter Neilson
1 sibling, 0 replies; 8+ messages in thread
From: Peter Neilson @ 2016-02-03 11:44 UTC (permalink / raw)
To: emacs-orgmode
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."
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-02-04 7:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-02 13:56 Stackoverflow in regexp matcher Loris Bennett
2016-02-02 15:47 ` Nick Dokos
2016-02-03 7:36 ` Loris Bennett
2016-02-03 11:19 ` Nicolas Goaziou
2016-02-03 11:34 ` Loris Bennett
2016-02-03 17:50 ` Alan Schmitt
2016-02-04 7:30 ` Loris Bennett
2016-02-03 11:44 ` Peter Neilson
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).