This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug regex/934] segfault in regexec


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]