Created attachment 324193 [details] Upstream Patch Description of problem: There is a const-correctness bug in Boost.Regex-1.33.x that strikes only in multithreaded programs on Unix platforms. This message describes the problem and has a patch for the issue: http://lists.boost.org/Archives/boost/2006/07/108576.php I checked that boost-1.33.1-10.el5.src.rpm does not include the patch nor the workaround, and that there are no bugs in RH's Bugzilla for boost/regex. Version-Release number of selected component (if applicable): 1.33.1-10 How reproducible: Race condition. Steps to Reproduce: * Multiple threads construct regexes concurrently, or * Multiple threads perform search and replace operations concurrently. Couldn't give more details than that. Actual results: N/A Expected results: N/A Additional info: I attached the upstream patch to the bug, this is the original URL http://lists.boost.org/Archives/boost/att-108576/regex-thread.diff It applies cleanly on boost-1.33.1-10.el5.src.rpm Thanks, Filipe
Created attachment 516143 [details] Test case Compile the test case and run it like this: > ./a.out # this for single-threaded run. This should never fail > ./a.out a # this for multi-threaded run. This fails before the fix: terminate called recursively terminate called after throwing an instance of 'boost::regex_error' what(): Invalid content of repeat range The actual bug can be different: > ./a.out a terminate called after throwing an instance of 'boost::regex_errorterminate called recursively ' what(): Invalid content of repeat range This goes away after the fix.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Prior to this update, when several regular expression objects were created simultaneously, such as in a multi-threaded program, the construction of one of them sometimes failed. With this update, the object variables have been moved from the shared memory to the stack, thereby making the constructing function thread safe.
Created attachment 517410 [details] Test case ... hopefully the right file this time around.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0305.html