develooper Front page | perl.perl5.porters | Postings from July 2009

Re: [perl #68020] Evil combination of regexes, lexicals, and autovivication

Thread Previous
From:
Nicholas Clark
Date:
July 30, 2009 05:45
Subject:
Re: [perl #68020] Evil combination of regexes, lexicals, and autovivication
Message ID:
20090730124506.GT60303@plum.flirble.org
On Wed, Jul 29, 2009 at 11:46:39AM -0700, John Peacock wrote:

> Schwern and I simultaneously discovered that some hash tests were 
> failing in Damian's Regex::Grammars.  But it turns out to be some 
> insideous combination of regexes, lexicals, and autovivication and not 
> depend on R::G at all.  Damian came up with the following script:
> 
>    use 5.010;
> 
>    my $rx = qr{ (?{ @arr = [1]; $arr[-1][0] = 0; my $var; }) }x;
> 
>    #my $dummy1 = '';
>    #my $dummy2 = '';
> 
>    my $line = "";
>    $line =~ $rx;
> 
>    say 'fail' if !defined $line;

On Linux, with blead, valgrind says:

==32406== Invalid read of size 8
==32406==    at 0x5DE7BC: Perl_leave_scope (scope.c:839)
==32406==    by 0x67E829: S_regmatch (regexec.c:5360)
==32406==    by 0x6702D4: S_regtry (regexec.c:2346)
==32406==    by 0x66F238: Perl_regexec_flags (regexec.c:2142)
==32406==    by 0x53C255: Perl_pp_match (pp_hot.c:1355)
==32406==    by 0x4F5D5C: Perl_runops_debug (dump.c:2017)
==32406==    by 0x4492E3: S_run_body (perl.c:2282)
==32406==    by 0x448806: perl_run (perl.c:2208)
==32406==    by 0x41F6DC: main (perlmain.c:117)
==32406==  Address 0x5c640d0 is 8 bytes after a block of size 32 alloc'd
==32406==    at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==32406==    by 0x4F6657: Perl_safesysmalloc (util.c:94)
==32406==    by 0x528615: Perl_av_extend (av.c:183)
==32406==    by 0x52A5D0: Perl_av_store (av.c:352)
==32406==    by 0x4A9C50: Perl_pad_new (pad.c:208)
==32406==    by 0x447BA2: S_parse_body (perl.c:2011)
==32406==    by 0x446CE4: perl_parse (perl.c:1600)
==32406==    by 0x41F6C7: main (perlmain.c:115)
==32406==
==32406== Invalid read of size 4
==32406==    at 0x5DE891: Perl_leave_scope (scope.c:849)
==32406==    by 0x67E829: S_regmatch (regexec.c:5360)
==32406==    by 0x6702D4: S_regtry (regexec.c:2346)
==32406==    by 0x66F238: Perl_regexec_flags (regexec.c:2142)
==32406==    by 0x53C255: Perl_pp_match (pp_hot.c:1355)
==32406==    by 0x4F5D5C: Perl_runops_debug (dump.c:2017)
==32406==    by 0x4492E3: S_run_body (perl.c:2282)
==32406==    by 0x448806: perl_run (perl.c:2208)
==32406==    by 0x41F6DC: main (perlmain.c:117)
==32406==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

Lines 837 to 849 are:

	case SAVEt_CLEARSV:
	    ptr = (void*)&PL_curpad[SSPOPLONG];
	    sv = *(SV**)ptr;

	    DEBUG_Xv(PerlIO_printf(Perl_debug_log,
	     "Pad 0x%"UVxf"[0x%"UVxf"] clearsv: %ld sv=0x%"UVxf"<%"IVdf"> %s\n",
		PTR2UV(PL_comppad), PTR2UV(PL_curpad),
		(long)((SV **)ptr-PL_curpad), PTR2UV(sv), (IV)SvREFCNT(sv),
		(SvREFCNT(sv) <= 1 && !SvOBJECT(sv)) ? "clear" : "abandon"
	    ));

	    /* Can clear pad variable in place? */
	    if (SvREFCNT(sv) <= 1 && !SvOBJECT(sv)) {


I don't know why/how ptr ends up as garbage. The block it is 1 pointer beyond
was allocated by this bit of pad.c

	av_store(pad, 0, NULL);


I hope this gives someone some insight, as this is about as far as I can go.

Nicholas Clark

Thread Previous


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