emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(error "Stack overflow in regexp matcher") and (?)wrong display of regex


From: Alan Mackenzie
Subject: (error "Stack overflow in regexp matcher") and (?)wrong display of regexp in backtrace
Date: Sun, 15 Mar 2020 10:39:22 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Emacs.

I'm not sure whether I've tripped over bugs or not here, so I'm posting
to emacs-devel.

1. Start the Emacs-27 pretest or master with -Q.
2. Visit the file given for bug #40052, namely:

    
http://hg.openjdk.java.net/jdk/jdk/raw-file/29edf1cb3c02/src/hotspot/share/runtime/globals.hpp

.  (Note: this file is one gigantic #define macro and is thus slow to
scroll, etc.  That is the topic of bug #40052.)
3. M-: (setq debug-on-error t)
4. move point to the #define at line 115.
5. Type a space.

This causes a stack overflow error in the regexp engine, producing this
backtrace:

Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
  re-search-forward("\\(\\\\\\(.\\|\n\\)\\|[^\\\n\15]\\)*" nil t)
  c-before-change-check-unbalanced-strings(5717 5717)
  #f(compiled-function (fn) #<bytecode 
0x158b20edb5bd>)(c-before-change-check-unbalanced-strings)
  mapc(#f(compiled-function (fn) #<bytecode 0x158b20edb5bd>) 
(c-extend-region-for-CPP c-before-change-check-raw-strings 
c-before-change-check-<>-operators c-depropertize-CPP c-invalidate-macro-cache 
c-truncate-bs-cache c-before-change-chec$
  c-before-change(5717 5717)
  self-insert-command(1 32)
  funcall-interactively(self-insert-command 1 32)
  call-interactively(self-insert-command nil nil)
  command-execute(self-insert-command)

First of all, note the regexp, "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\15]\\)*"
                                                            ^^^
In the source, the "\15" is "\r".  Why is this substitution being made
for the backtrace?  Is it intentional (in which case, why not do the
same to the "\n"?), or is it a bug?  To me, it is more like a bug.

More importantly, why is there a stack overflow here at all?  Even
though the regexp matcher has a long, long piece of buffer to scan over,
the regexp is a simple linear search, without any nesting to speak of.
There would appear to be no need for any backtracking.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]