GNU bug report logs - #22149
stack overflow in regexp matcher

Previous Next

Package: emacs;

Reported by: Cheng-An Yang <rhymer123 <at> gmail.com>

Date: Sat, 12 Dec 2015 06:32:01 UTC

Severity: normal

Tags: confirmed

Found in versions 24.4, 25.0.95

Fixed in version 28.1

Done: Mattias EngdegÄrd <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mattias EngdegÄrd <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, rhymer123 <at> gmail.com, npostavs <at> gmail.com, 22149 <at> debbugs.gnu.org
Subject: bug#22149: 24.4; gdb stack overflow in regexp matcher
Date: Fri, 13 Mar 2020 21:11:05 +0100
13 mars 2020 kl. 20.39 skrev Eli Zaretskii <eliz <at> gnu.org>:

> I don't understand what that does to fix the problem, and don't really
> see why it would be urgent to fix in Emacs 27.  Can you explain?

It's not urgent, but it is a bug that gdb-mi crashes with a regexp stack overflow for certain strings.
What the patch does is replacing the regexp fragment

 (* (or (not (any ?\" ?\\))
        (seq ?\\ nonl)))

with

 (* (or (seq ?\\ nonl)
        (not (any ?\" ?\\))))

Ie, try the least likely branch first (backslash-escaped char) in the inner loop, so that the successful branch is last and won't grow the regexp stack.

The effect is readily seen in an even simpler example:

 (string-match "^\\(?:a\\|b\\)*c" (make-string 160000 ?a))

crashes, but

 (string-match "^\\(?:b\\|a\\)*c" (make-string 160000 ?a))

works (ie, fails to match).

It was suggested for Emacs 27 since it's a known bug with a simple solution. Then again, it's not a regression from a recent release.





This bug report was last modified 5 years and 60 days ago.

Previous Next


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