unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattiase@acm.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 34910@debbugs.gnu.org
Subject: bug#34910: 27.0.50; Too much matching reentrancy
Date: Tue, 19 Mar 2019 13:25:13 +0100	[thread overview]
Message-ID: <67b98e6f3b032e7114568934c94d32127897f5d2.camel@acm.org> (raw)
In-Reply-To: <8336njuqrd.fsf@gnu.org>

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

tis 2019-03-19 klockan 12:01 +0200 skrev Eli Zaretskii:
> 
> I don't know yet.  I asked you to elaborate on the reasons for your
> expectations, and I still hope you will humor me.  Because just
> taking the problem's manifestations at face value, one could argue
> that the precise error message is immaterial, as long as it points to
> the right direction, and "stack overflow in regexp matcher" is as
> obscure as the other message.  But maybe I'm missing something, which
> is why I asked you to elaborate on your reasoning.

Sorry, I didn't mean to sound touchy! Being the bug reporter, I deserve
every probing question. I'm most grateful for your quick reply!

It turns out the regexp cache logic is broken: it always uses the last
(LRU) entry, and fails if that entry is busy. It should really use the
last free entry.

What happened was that a regexp failed because of stack overflow, which
caused lots of code to run and many regexps to be compiled, but the
original (failing) regexp was still marked busy in the cache.
Eventually, it had been pushed down to the last position in the cache,
where it caused the next request for a free cache entry to fail with
the reentrancy error.

This patch fixes it. Please review.


[-- Attachment #2: 0001-Fix-spurious-regexp-reentrancy-error.patch --]
[-- Type: text/x-patch, Size: 2034 bytes --]

From 6ec7c354513a058fb0b396150ed3a7c1655e2a18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Tue, 19 Mar 2019 13:06:20 +0100
Subject: [PATCH] Fix spurious regexp reentrancy error

src/search.c (compile_pattern): Don't give up if the last regexp cache
entry is busy.  Instead, use the last (least recently used) non-busy
entry, and only report the reentrancy error if there is no free entry
at all (Bug#34910).
---
 src/search.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/search.c b/src/search.c
index a1e0b0976e..2c00e6e93f 100644
--- a/src/search.c
+++ b/src/search.c
@@ -223,11 +223,13 @@ static struct regexp_cache *
 compile_pattern (Lisp_Object pattern, struct re_registers *regp,
 		 Lisp_Object translate, bool posix, bool multibyte)
 {
-  struct regexp_cache *cp, **cpp;
+  struct regexp_cache *cp, **cpp, **lru_nonbusy;
 
-  for (cpp = &searchbuf_head; ; cpp = &cp->next)
+  for (cpp = &searchbuf_head, lru_nonbusy = NULL; ; cpp = &cp->next)
     {
       cp = *cpp;
+      if (!cp->busy)
+        lru_nonbusy = cpp;
       /* Entries are initialized to nil, and may be set to nil by
 	 compile_pattern_1 if the pattern isn't valid.  Don't apply
 	 string accessors in those cases.  However, compile_pattern_1
@@ -247,13 +249,14 @@ compile_pattern (Lisp_Object pattern, struct re_registers *regp,
 	  && cp->buf.charset_unibyte == charset_unibyte)
 	break;
 
-      /* If we're at the end of the cache, compile into the nil cell
-	 we found, or the last (least recently used) cell with a
-	 string value.  */
+      /* If we're at the end of the cache, compile into the last
+	 (least recently used) non-busy cell in the cache.  */
       if (cp->next == 0)
 	{
-          if (cp->busy)
+          if (!lru_nonbusy)
             error ("Too much matching reentrancy");
+          cpp = lru_nonbusy;
+          cp = *cpp;
 	compile_it:
           eassert (!cp->busy);
 	  compile_pattern_1 (cp, pattern, translate, posix);
-- 
2.20.1


  reply	other threads:[~2019-03-19 12:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-18 21:34 bug#34910: 27.0.50; Too much matching reentrancy Mattias Engdegård
2019-03-19  8:05 ` Eli Zaretskii
2019-03-19  9:27   ` Mattias Engdegård
2019-03-19 10:01     ` Eli Zaretskii
2019-03-19 12:25       ` Mattias Engdegård [this message]
2019-03-19 12:31         ` Eli Zaretskii
2019-03-30  9:29         ` Eli Zaretskii
2019-03-19 12:50       ` Mattias Engdegård
2019-03-30  9:30         ` Eli Zaretskii
2019-03-30 11:18           ` Mattias Engdegård
2019-03-30 14:52             ` Daniel Colascione
2019-03-30 12:55           ` Stefan Monnier
2019-03-30 13:05             ` Mattias Engdegård
2019-03-30 13:37               ` Eli Zaretskii
2019-03-30 16:22               ` Stefan Monnier
2019-03-30 17:10                 ` Daniel Colascione
2019-03-30 19:06                   ` Mattias Engdegård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=67b98e6f3b032e7114568934c94d32127897f5d2.camel@acm.org \
    --to=mattiase@acm.org \
    --cc=34910@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.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).