Stack overflow in regexp matcher

[brabalan]

With an up to date emacs, org, and git gnus, I get the following backtrace for some messages. Is it a gnorb bug or an org bug?

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("/Users/schmitta/Documents/Org/")
  byte-code("…" [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 "…" [save-match-data-internal set-match-data evaporate] 3)) ((byte-code "…" [save-match-data-internal set-match-data evaporate] 3)) reftex-label-info 3 92 -1 5 "Scanning %s %s ..." rassoc 6 delq mapcar #[(x) "…" [x include-file string-match] 3] reftex-parse-from-file 9 reftex-init-section-numbers appendix 10 ...] 7)
  reftex-parse-from-file("/Users/schmitta/Documents/Org/todo-orgx.org" nil "/Users/schmitta/Documents/Org/")
  reftex-do-parse(1 nil)
  reftex-access-scan-info((16))
  reftex-parse-all()
  (progn (reftex-parse-all) (reftex-set-cite-format (quote ((98 . "[[bib:%l][%l-bib]]") (99 . "\\cite{%l}") (110 . "[[note:%l][%l-note]]") (108 . "%t (%a)\n[[bibdesk:/Users/schmitta/projets/bib/alan.bib::%l][%l-BibDesk]]") (116 . "%t") (104 . "** %t (%a)\n:PROPERTIES:\n:Custom_ID: %l\n:END:\n[[bib:%l][%l-bib]]\n[[bibdesk:/Users/schmitta/projets/bib/alan.bib::%l][%l-BibDesk]]")))))
  (and (buffer-file-name) (file-exists-p (buffer-file-name)) (progn (reftex-parse-all) (reftex-set-cite-format (quote ((98 . "[[bib:%l][%l-bib]]") (99 . "\\cite{%l}") (110 . "[[note:%l][%l-note]]") (108 . "%t (%a)\n[[bibdesk:/Users/schmitta/projets/bib/alan.bib::%l][%l-BibDesk]]") (116 . "%t") (104 . "** %t (%a)\n:PROPERTIES:\n:Custom_ID: %l\n:END:\n[[bib:%l][%l-bib]]\n[[bibdesk:/Users/schmitta/projets/bib/alan.bib::%l][%l-BibDesk]]"))))))
  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()
  set-auto-mode-0(org-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer todo-orgx.org> "~/Documents/Org/todo-orgx.org" nil nil "~/Documents/Org/todo-orgx.org" (6928954 16777220))
  find-file-noselect("~/Documents/Org/todo-orgx.org")
  org-get-agenda-file-buffer("~/Documents/Org/todo-orgx.org")
  org-id-find-id-in-file("D4676485-1E06-451D-8F08-F0906FF3885C" "~/Documents/Org/todo-orgx.org" t)
  org-id-find("D4676485-1E06-451D-8F08-F0906FF3885C" t)
  gnorb-pretty-outline("D4676485-1E06-451D-8F08-F0906FF3885C" t)
  gnorb-gnus-hint-relevant-message()
  run-hooks(gnus-article-prepare-hook)
  apply(run-hooks gnus-article-prepare-hook)
  gnus-run-hooks(gnus-article-prepare-hook)
  gnus-article-prepare(6548 nil)
  gnus-summary-display-article(6548)
  gnus-summary-next-article(nil)
  call-interactively(gnus-summary-next-article nil nil)
  command-execute(gnus-summary-next-article)

[girzel]

Weird! As you can see from the backtrace, gnorb-pretty-outline hands off to org-id-find early on, and it's all Org code after that. But if you're only getting it via Gnorb code, that's suspicious. When you get this error, is it for headings in files you haven't opened yet? Ie, you don't yet have a buffer visiting that file?

[girzel]

Mm, stupid question, obviously the file is being visited for the first time here. Hang on and let me see if maybe I shouldn't be using a different org-id function to visit the headline...

[brabalan]

I confirm it's for a file not visited yet (I rebooted emacs, and I read an email with a related todo).

[brabalan]

As I just had the issue with an org file, this is not a gnorb problem. In fact I'm suspecting it's not an org problem either but an auctex one. In any case, I'm closing this issue.