From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12066 invoked by alias); 6 May 2005 08:13:19 -0000 Mailing-List: contact glibc-bugs-regex-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-regex-owner@sources.redhat.com Received: (qmail 8443 invoked by uid 48); 6 May 2005 08:11:48 -0000 Date: Fri, 06 May 2005 08:13:00 -0000 Message-ID: <20050506081148.8442.qmail@sourceware.org> From: "zachmann at schlund dot de" To: glibc-bugs-regex@sources.redhat.com In-Reply-To: <20050506060600.934.zachmann@schlund.de> References: <20050506060600.934.zachmann@schlund.de> Reply-To: sourceware-bugzilla@sources.redhat.com Subject: [Bug regex/934] segfault in regexec X-Bugzilla-Reason: CC X-SW-Source: 2005-05/txt/msg00002.txt.bz2 List-Id: ------- 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.