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
View this message in rfc822 format
18 sep. 2023 kl. 14.32 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> In the mean time the patch below recognizes the above pattern, which
> gives me code which is safe (it should both always terminate and should
> never apply the optimization if it's not valid) yet does find the
> optimization in all the cases where I expected it.
Yes, maybe this would work but the ad-hocness of it all means that I very much could have missed something (and as you comment, that it's brittle).
> case succeed_n:
> - /* If N == 0, it should be an on_failure_jump_loop instead. */
> - DEBUG_STATEMENT (EXTRACT_NUMBER (j, p + 2); eassert (j > 0));
> + /* If N == 0, it should be an on_failure_jump_loop instead.
> + `j` can be negative because `EXTRACT_NUMBER` extracts a
> + signed number whereas `succeed_n` treats it as unsigned. */
> + DEBUG_STATEMENT (EXTRACT_NUMBER (j, p + 2); eassert (j != 0));
So this is what prevented me from running with counts above 2**15 and debugging enabled for all these years...
> + if (loop_exit && p2 > loop_exit)
> + {
> + void print_compiled_pattern (struct re_pattern_buffer *bufp);
> + print_compiled_pattern (bufp);
> + fprintf (stderr, "p1==%d, p2==%d, loop-entry==%d, loop-exit==%d\n",
> + p1 - bufp->buffer, p2 - bufp->buffer,
> + loop_entry - bufp->buffer, loop_exit - bufp->buffer);
> + error ("WOW1!");
#ifdef REGEX_EMACS_DEBUG ?
> + }
> + /* return false; */
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.