GNU bug report logs - #65726
29.1.50; Crash in regexp engine

Previous Next

Package: emacs;

Reported by: martin rudalics <rudalics <at> gmx.at>

Date: Mon, 4 Sep 2023 07:48:02 UTC

Severity: normal

Found in version 29.1.50

Fixed in version 30.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #48 received at 65726 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 65726 <at> debbugs.gnu.org
Subject: Re: bug#65726: 29.1.50; Crash in regexp engine
Date: Tue, 05 Sep 2023 09:08:01 -0400
> Thank you for fixing it, but now regex-emacs-tests fail with a regexp stack
> overflow.

Really?  I thought I had specifically run that test.
[ ...recompiling + rerunning the test... ]
Hmm... you're right.  Crap.

> It seems that by fixing this bug, we've unfixed the one that the
> broken code was supposed to fix.

Well, that one was less of a bug (more of a missing optimization), so
it's no reason to revert the change, but yes, not good.
Let's see if I can finagle something.

> And we should probably include a regression test for this bug as well.
> The previously mentioned
>
>   (string-match (rx (* "a") (* (* "b"))) "a")
>
> might suffice, but extending it to
>
>   (string-match (rx (* "a") (* (or "c" (* "b")))) "a")
>
> is safer in case the regexp compiler decides to simplify (* (* X)) -> (* X).

Feel free.  To me, it feels too much like testing the presence/absence
of a very specific bug (i.e. too unlikely that we'll reintroduce that
exact bug.  It's not like it was a weird case I didn't think of).


        Stefan





This bug report was last modified 1 year and 242 days ago.

Previous Next


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