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: "paolo dot bonzini at lu dot unisi dot ch" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs-regex at sources dot redhat dot com
- Date: 6 May 2005 08:19:20 -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 paolo dot bonzini at lu dot unisi dot ch 2005-05-06 08:19 -------
Subject: Re: segfault in regexec
>So there should be no internal states in regex_t or I'm wrong here?
>
>
Hm, re_acquire_state and other functions that *create* these states
should be guarded.
>>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.
>
>
Oh right, because this one runs longer but not in re_acquire_state_context.
Paolo
--
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.