https://bugzilla.redhat.com/show_bug.cgi?id=989921 Bug ID: 989921 Summary: perl-5.18: Null optimization in regular expression engine causes segfault and other errors Product: Fedora Version: rawhide Component: perl Assignee: mmaslano@xxxxxxxxxx Reporter: ppisar@xxxxxxxxxx QA Contact: extras-qa@xxxxxxxxxxxxxxxxx CC: cweyl@xxxxxxxxxxxxxxx, iarnell@xxxxxxxxx, jplesnik@xxxxxxxxxx, kasal@xxxxxx, mmaslano@xxxxxxxxxx, perl-devel@xxxxxxxxxxxxxxxxxxxxxxx, ppisar@xxxxxxxxxx, psabata@xxxxxxxxxx, rc040203@xxxxxxxxxx, tcallawa@xxxxxxxxxx $ perl -e 'x =~ /(?:(a(*SKIP)b)){0}(?:(?1)|ac)/' Infinite recursion in regex at -e line 1. $ perl -e 'qr{(?&foo){0}(?<foo>)}' Segmentation fault $ rpm -q perl perl-5.18.0-285.fc20.x86_64 This is a regression since perl-5.18.0. Reported to upstream <https://rt.perl.org/rt3/Public/Bug/Display.html?id=119071> and fixed with commit: commit 2e3a23da260a7ec5d61b81cb34c38de5e528b41d Author: Karl Williamson <public@xxxxxxxxxxxxxxxx> Date: Mon Jul 1 10:26:14 2013 -0600 Fix regex seqfault 5.18 regression This segfault is a result of an optimization that can leave the compilation in an inconsistent state. /f{0}/ doesn't match anything, and hence should be removable from the regex for all f. However, qr{(?&foo){0}(?<foo>)} caused a segfault. What was happening prior to this commit is that (?&foo) refers to a named capture group further along in the regex. The "{0}" caused the "(?&foo)" to be discarded prior to setting up the pointers between the two related subexpressions; a segfault follows. This commit removes the optimization, and should be suitable for a maintenance release. One might think that no one would be writing code like this, but this example was distilled from machine-generated code in Regexp::Grammars. Perhaps this optimization can be done, but the location I chose for checking it was during parsing, which turns out to be premature. It would be better to do it in the optimization phase of regex compilation. Another option would be to retain it where it was, but for it to operate only on a limited set of nodes, such as EXACTish, which would have no unintended consequences. But that is for looking at in the future; the important thing is to have a simple patch suitable for fixing this regression in a maintenance release. For the record, the code being reverted was mistakenly added by me in commit 3018b823898645e44b8c37c70ac5c6302b031381, and wasn't even mentioned in that commit message. It should have had its own commit. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Slhntf3yXh&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
