develooper Front page | perl.perl5.porters | Postings from January 2017

Re: [perl #130561] Coredump in Perl_re_op_compile

Thread Previous | Thread Next
From:
demerphq
Date:
January 27, 2017 09:25
Subject:
Re: [perl #130561] Coredump in Perl_re_op_compile
Message ID:
CANgJU+XBn-03hXy8eVgvL-HjOVrVdeV7GyysPpiwCKPN20UPQA@mail.gmail.com
On 27 January 2017 at 07:21, demerphq <demerphq@gmail.com> wrote:
> On 26 January 2017 at 11:20, Hugo van der Sanden via RT
> <perlbug-followup@perl.org> wrote:
>> Ugh, I experimented with this some more, and found that after my patch to deoptimize this loops until stack exhaustion:
>>
>> ./miniperl -wle '"abaad" =~ m{(a) b ( ((?1)){2,1} | aa )d}x'
>
> That is because your patch did not change regexec.c to fail when the
> min/max are incorrect.

And I am wrong. I tried going down that road, and it is painful. So
painful I prepared a revert. But just before I was going to send it I
had an epiphany and hopefully 3rd time lucky.

Instead of converting the impossible construct into an OPFAIL, we can
inject an OPFAIL in *front* of the impossible construct. This means
that the construct is still reachable via recursion, but will never be
executed otherwise. And since we have not removed the OPEN/CLOSE the
segfaults that lead to this bugreport also go away.

So fixed in:

commit 31fc93954d1f379c7a49889d91436ce99818e1f6
Author: Yves Orton <demerphq@gmail.com>
Date:   Fri Jan 27 10:18:51 2017 +0100

    fix RT #130561 - recursion and optimising away impossible
quantifiers are not friends

    Instead of optimising away impossible quantifiers like (foo){1,0} treat them
    as unquantified, and guard them with an OPFAIL. Thus /(foo){1,0}/ is treated
    the same as /(*FAIL)(foo)/ this is important in patterns like
/(foo){1,0}|(?1)/
    where the (?1) needs to be able to recurse into the (foo) even though the
    (foo){1,0} can never match. It also resolves various issues
(SEGVs) with patterns
    like /((?1)){1,0}/.

    This patch would have been easier if S_reginsert() documented that it is
    the callers responsibility to properly set up the NEXT_OFF() of the inserted
    node (if the node has a NEXT_OFF())

Along with a couple of cleanup patches which would have made fixing this easier.

Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About