develooper Front page | perl.perl5.porters | Postings from September 2014

Re: [perl #122747] Assertion failed in Perl_reg_numbered_buff_fetch,file regcomp.c, line 7459

Thread Previous | Thread Next
From:
demerphq
Date:
September 11, 2014 20:49
Subject:
Re: [perl #122747] Assertion failed in Perl_reg_numbered_buff_fetch,file regcomp.c, line 7459
Message ID:
CANgJU+V-+F=A1g0P7Zgof7G8ct0gdbgiUUx-07jBCPDpaU3_Zg@mail.gmail.com
On 11 September 2014 22:00, demerphq <demerphq@gmail.com> wrote:

> On 11 September 2014 21:53, demerphq <demerphq@gmail.com> wrote:
>
>> On 11 September 2014 21:40, Father Chrysostomos via RT <
>> perlbug-followup@perl.org> wrote:
>>
>>> On Thu Sep 11 12:32:57 2014, demerphq wrote:
>>> > On 11 September 2014 20:41, demerphq <demerphq@gmail.com> wrote:
>>> > > Now I can replicate I have determined the the use re 'taint'; is
>>> > > apparently unnecessary, the script I posted which prints $1 will
>>> > > trigger it
>>> > > as well. Reattached in this mail...
>>> > >
>>> > > Since the re taint is not necessary this means the relation to the
>>> > > utf8
>>> > > loading and save_re_context and things like that is irrelevant.
>>> > >
>>> >
>>> > I was misreading things. In fact this is relevant:
>>> >
>>> > #0  0x00007ffff70e9037 in __GI_raise (sig=sig@entry=6) at
>>> > ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>> > #1  0x00007ffff70ec698 in __GI_abort () at abort.c:90
>>> > #2  0x00007ffff70e1e03 in __assert_fail_base (fmt=0x7ffff7239158
>>> > "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
>>> >     assertion=assertion@entry=0x7ce6b8 "(STRLEN)rx->sublen >=
>>> > (STRLEN)((s -
>>> > rx->subbeg) + i)", file=file@entry=0x7cb018 "regcomp.c",
>>> >     line=line@entry=7552, function=function@entry=0x7d5430
>>> > <__PRETTY_FUNCTION__.17671> "Perl_reg_numbered_buff_fetch") at
>>> > assert.c:92
>>> > #3  0x00007ffff70e1eb2 in __GI___assert_fail (assertion=0x7ce6b8
>>> > "(STRLEN)rx->sublen >= (STRLEN)((s - rx->subbeg) + i)",
>>> >     file=0x7cb018 "regcomp.c", line=7552, function=0x7d5430
>>> > <__PRETTY_FUNCTION__.17671> "Perl_reg_numbered_buff_fetch")
>>> >     at assert.c:101
>>> > #4  0x000000000051689b in Perl_reg_numbered_buff_fetch
>>> > (my_perl=0xa95010,
>>> > r=0xac4b68, paren=1, sv=0xacd388) at regcomp.c:7552
>>> > #5  0x00000000005721e6 in Perl_magic_get (my_perl=0xa95010,
>>> > sv=0xacd388,
>>> > mg=0xad36f8) at mg.c:789
>>> > #6  0x000000000056fc1f in Perl_mg_get (my_perl=0xa95010, sv=0xacd388)
>>> > at
>>> > mg.c:199
>>> > #7  0x000000000066352c in Perl_save_scalar (my_perl=0xa95010,
>>> > gv=0xacd370)
>>> > at scope.c:206
>>> > #8  0x0000000000542044 in Perl_save_re_context (my_perl=0xa95010) at
>>> > regcomp.c:16814
>>> > #9  0x00000000007183cb in Perl__core_swash_init (my_perl=0xa95010,
>>> > pkg=0x862a4e "utf8", name=0x862a09 "ToCf", listsv=0xa95138,
>>> >     minbits=4, none=0, invlist=0x0, flags_p=0x0) at utf8.c:2346
>>> > #10 0x0000000000716945 in Perl_to_utf8_case (my_perl=0xa95010,
>>> > p=0xabf0ba
>>> > "”", ustrp=0x7fffffffd390 "\f", lenp=0x7fffffffd338,
>>> >     swashp=0xa958c8, normal=0x862a09 "ToCf", special=0x86272a "") at
>>> > utf8.c:1800
>>> > #11 0x0000000000717c24 in Perl__to_utf8_fold_flags (my_perl=0xa95010,
>>> > p=0xabf0ba "”", ustrp=0x7fffffffd390 "\f",
>>> >     lenp=0x7fffffffd338, flags=2 '\002') at utf8.c:2161
>>> > #12 0x0000000000721be7 in Perl_foldEQ_utf8_flags (my_perl=0xa95010,
>>> > s1=0xacc974 "phone", pe1=0x0, l1=5, u1=false, s2=0xabf0ba "”",
>>> >     pe2=0x7fffffffd500, l2=0, u2=true, flags=0) at utf8.c:4044
>>> > #13 0x0000000000701990 in S_regmatch (my_perl=0xa95010,
>>> > reginfo=0x7fffffffddf0, startpos=0xabf0a4 "xxxx.xxxx@outlook.com ”",
>>> >     prog=0xacc8c8) at regexec.c:4561
>>> > #14 0x00000000006fb104 in S_regtry (my_perl=0xa95010,
>>> > reginfo=0x7fffffffddf0, startposp=0x7fffffffdc50) at regexec.c:3231
>>> > #15 0x00000000006fa9fc in Perl_regexec_flags (my_perl=0xa95010,
>>> > rx=0xac4b68,
>>> >     stringarg=0xabf098 "A¹kerèeva xxxx.xxxx@outlook.com ”",
>>> > strend=0xabf0ac
>>> > "x@outlook.com ”",
>>> >     strbeg=0xabf098 "A¹kerèeva xxxx.xxxx@outlook.com ”", minend=0,
>>> > sv=0xa98078, data=0x0, flags=1) at regexec.c:3090
>>> > #16 0x00000000005bd269 in Perl_pp_subst (my_perl=0xa95010) at
>>> > pp_hot.c:2120
>>> > #17 0x000000000055ad69 in Perl_runops_debug (my_perl=0xa95010) at
>>> > dump.c:2353
>>> > #18 0x000000000045e9a2 in S_run_body (my_perl=0xa95010, oldscope=1) at
>>> > perl.c:2416
>>> > #19 0x000000000045dd66 in perl_run (my_perl=0xa95010) at perl.c:2339
>>> > #20 0x000000000041b35d in main (argc=3, argv=0x7fffffffe3f8,
>>> > env=0x7fffffffe418) at perlmain.c:114
>>>
>>> So you’ve beaten me to the backtrace.
>>>
>>> Yes, sorry about that. Configure was driving me bonkers.
>>
>>
>>> > Do we really need to use the regex engine for swash init? Wouldnt the
>>> > sanest way to solve this class of bugs be to change how we store and
>>> > represent swashes?
>>>
>>> Short of that, could we just stop the init code from using regexps
>>> itself?
>>>
>>>
>> That is what I meant.
>>
>>
>>> That said, is it even necessary at present to localise $1 et al.?  As
>>> long as the swash init code does not access $1 after a failed match, would
>>> it matter that the current (outer) regexp is in an inconsistent state?  Or
>>> could we make PL_curpm null during the swash init?
>>>
>>
>> The latter is an amazingly good idea and I am testing a patch that does
>> exactly that as I type.
>>
>>
> It passed basic regex tests. I am running a full test now, but at the same
> time I pushed smoke-me/rt_122747 which includes
>
> commit 55b10d6c41f252b3256cf96b3bdf903eb6a7fb57
> Author: Yves Orton <demerphq@gmail.com>
> Date:   Thu Sep 11 21:55:08 2014 +0200
>
>     perl #122747: localize PL_curpm to null in _core_swash_init
>
>     This is a naive patch to set PL_curpm to null before we do any
>     swash intialization. This "hides" the current regop from the swash
>     code, with the intent of prevent weird reentrancy bugs.
>
>     Thanks to FC for the suggestion!
>
>
And now I just pushed to blead:

commit 2c1f00b9036a7987c714a407662651ef7da99495
Author: Yves Orton <demerphq@gmail.com>
Date:   Thu Sep 11 21:55:08 2014 +0200

    perl #122747: localize PL_curpm to null in _core_swash_init

    Set PL_curpm to null before we do any swash intialization
    in _core_swash_init(). This "hides" the current regop from the
    swash code, with the intent of prevent weird reentrancy bugs
    when the swashes are initialized.

    Long term you could argue that we should just not use the regex
    engine to initialize a swash, and then this would be unnecessary.

    Thanks to FC for the suggestion!


I believe that this ticket can be closed.

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