This is the mail archive of the
glibc-bugs-regex@sources.redhat.com
mailing list for the glibc project.
[Bug regex/934] segfault in regexec
- From: "zachmann at schlund dot de" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs-regex at sources dot redhat dot com
- Date: 6 May 2005 08:11:48 -0000
- Subject: [Bug regex/934] segfault in regexec
- References: <20050506060600.934.zachmann@schlund.de>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From zachmann at schlund dot de 2005-05-06 08:11 -------
But if I'm not mistaken the IEEE Std 1003.1, 2004 Edition states:
"The interface is defined so that the matched substrings rm_sp and rm_ep are
in a separate regmatch_t structure instead of in regex_t. This allows a single
compiled RE to be used simultaneously in several contexts; in main() and a
signal handler, perhaps, or in multiple threads of lightweight processes. (The
preg argument to regexec() is declared with type const, so the implementation
is not permitted to use the structure to store intermediate results.)"
from:
http://www.opengroup.org/onlinepubs/000095399/functions/regcomp.html
So there should be no internal states in regex_t or I'm wrong here?
(In reply to comment #1)
> Probably, trying with a long running regex would make the crash almost
> 100% reproducible on both single and multi-processor machines. I'd try
> with ^(.)?(.?)(.?)(.?)(.?)\5\4\3\2\1$ for example.
with this regex it only crashes only in 5 out of 100 runs.
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=934
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.