GNU bug report logs -
#65726
29.1.50; Crash in regexp engine
Previous Next
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 #57 received at 65726 <at> debbugs.gnu.org (full text, mbox):
5 sep. 2023 kl. 17.33 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> You can ignore the `mutually_exclusive_(charset|exactn)` thingies which
> just move code around (it's necessary for the patch).
Actually that's a good refactoring to start with regardless of the path we follow later. Makes things more readable if nothing else.
> The basic idea is that `done` points to the beginning of the "current
> loop": as long as we move forward we presume we may still be in the
> current loop, and when we find a jump backward it's either a jump to the
> beginning of a new (nested/further) loop (so we move `done`) or a jump
> to the same loop or to some earlier loop (which we presumably handle
> elsewhere).
So how can we describe the exact semantics of `done` in mutually_exclusive_aux(p1,p2,done)?
Something like:
Let me(p1,p2) = true iff (p1 matches) implies (p2 fails).
Then me_aux(p1,p2,done) = me(p1,p2)
under the assumption that me(p1,x) holds for all x<done where x is reachable from p2.
?
> Adding an `assert (p2 >= done)` confirms that this does happen,
Can you give an example of such a regexp? I ran `make check` with your patch applied and checking enabled but got no assertion failure.
> so
> whether we return true or false when `p2 < done` does matter, so I guess
> we should go with the safer option unless we can really convince
> ourselves that the more optimistic option is also correct.
>
> Then again, maybe we should bite the bullet and actually keep track of
> the positions already visited, so we don't need any "fancy" argument.
There are a couple of ways of doing that but it might not be that bad. It would also be more robust in face of future changes that may not obey the current invariants.
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.