Re: valgrind finding from blead

[Steve Peters <steve@fisharerojo.org>]

On Fri, Oct 28, 2005 at 10:51:27PM +0300, Jarkko Hietaniemi wrote:
> valgrind 2.4.0 gives me from
> 
> $_ = 'a';
> $r = 'x';
> s/a(?{})/$r/;
> my $f = eval '$&';
> 
> the following:
> 
> ==18571== Invalid read of size 1
> ==18571==    at 0x1BA084DD: memmove (in /lib/libc-2.3.2.so)
> ==18571==    by 0x80EB5A4: Perl_sv_setpvn (sv.c:4373)
> ==18571==    by 0x80C8E54: Perl_magic_get (mg.c:844)
> ==18571==    by 0x80C779B: Perl_mg_get (mg.c:166)
> ==18571==    by 0x80E9D83: Perl_sv_setsv_flags (sv.c:3899)
> ==18571==    by 0x80F18F0: Perl_sv_mortalcopy (sv.c:7146)
> ==18571==    by 0x811C15C: Perl_pp_leaveeval (pp_ctl.c:3555)
> ==18571==    by 0x80BFD9C: Perl_runops_debug (dump.c:1597)
> ==18571==    by 0x8063877: S_run_body (perl.c:2290)
> ==18571==    by 0x80633D2: perl_run (perl.c:2217)
> ==18571==    by 0x805EC3D: main (perlmain.c:103)
> ==18571==  Address 0x1BAECB28 is 0 bytes inside a block of size 8 free'd
> ==18571==    at 0x1B904B04: free (vg_replace_malloc.c:152)
> ==18571==    by 0x80C0656: Perl_safesysfree (util.c:155)
> ==18571==    by 0x810F844: Perl_pp_substcont (pp_ctl.c:242)
> ==18571==    by 0x80BFD9C: Perl_runops_debug (dump.c:1597)
> ==18571==    by 0x8063877: S_run_body (perl.c:2290)
> ==18571==    by 0x80633D2: perl_run (perl.c:2217)
> ==18571==    by 0x805EC3D: main (perlmain.c:103)
> 

Sun Studio shows the sprintf below in Perl_sv_compile_2op() to be the source
of the biggest leak when running the above code.  Line numbers from blead's
pp_ctl.c

   2739     if (IN_PERL_COMPILETIME) {
   2740         SAVECOPSTASH_FREE(&PL_compiling);
   2741         CopSTASH_set(&PL_compiling, PL_curstash);
   2742     }
   2743     if (PERLDB_NAMEEVAL && CopLINE(PL_curcop)) {
   2744         SV * const sv = sv_newmortal();
   2745         Perl_sv_setpvf(aTHX_ sv, "_<(%.10seval %lu)[%s:%"IVdf"]",
   2746                        code, (unsigned long)++PL_evalseq,
   2747                        CopFILE(PL_curcop), (IV)CopLINE(PL_curcop));
   2748         tmpbuf = SvPVX(sv);
   2749     }
   2750     else
   2751         sprintf(tmpbuf, "_<(%.10s_eval %lu)", code, (unsigned long)++PL_evalseq)        ;
   2752     SAVECOPFILE_FREE(&PL_compiling);
   2753     CopFILE_set(&PL_compiling, tmpbuf+2);
   2754     SAVECOPLINE(&PL_compiling);
   2755     CopLINE_set(&PL_compiling, 1);
   2756     /* XXX For C<eval "...">s within BEGIN {} blocks, this ends up
   2757        deleting the eval's FILEGV from the stash before gv_check() runs
   2758        (i.e. before run-time proper). To work around the coredump that
   2759        ensues, we always turn GvMULTI_on for any globals that were
   2760        introduced within evals. See force_ident(). GSAR 96-10-12 */
   2761     len = strlen(tmpbuf);
   2762     safestr = savepvn(tmpbuf, len);
   2763     SAVEDELETE(PL_defstash, safestr, len);
   2764     SAVEHINTS();

Steve Peters
steve@fisharerojo.org

---

Follow-Ups from:

Jarkko Hietaniemi <jhietaniemi@gmail.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---