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

[perl #67902] Access Violation when mixing scalar values and sharedclones

From:
Dan Collins via RT
Date:
July 21, 2016 16:55
Subject:
[perl #67902] Access Violation when mixing scalar values and sharedclones
Message ID:
rt-4.0.18-12153-1469120126-536.67902-15-0@perl.org
On Fri Jul 10 20:01:12 2015, vega.james@gmail.com wrote:
> On Tue, Jul 28, 2009 at 12:46:44PM +0100, Nicholas Clark wrote:
> > On Sun, Jul 26, 2009 at 01:14:24PM -0700, Erland Sommarskog wrote:
> > > ...............................
> > > use strict;
> > > use threads;
> > > use threads::shared;
> > >
> > > my $td : shared = shared_clone({});
> > >
> > > warn "Write a string\n";
> > > $td->{Input} = "somestring";
> > >
> > > warn "Write an array reference\n";
> > > $td->{Input} = shared_clone([]);
> > >
> > > warn "Write a new string\n";
> > > $td->{Input} = "shoestring";
> > > .................................
> >
> > The bug is still present in blead, and I can replicate it on Linux.
> > valgrind shows it to be a NULL pointer dereference:
> >
> > ==22776== Invalid write of size 1
> > ==22776==    at 0x4C23C84: memmove (mc_replace_strmem.c:517)
> > ==22776==    by 0x593E81: Perl_sv_setsv_flags (sv.c:4063)
> > ==22776==    by 0x66A2829: sharedsv_scalar_store (shared.xs:766)
> > ==22776==    by 0x66A4911: sharedsv_elem_mg_STORE (shared.xs:947)
> > ==22776==    by 0x520F0D: Perl_mg_set (mg.c:293)
> > ==22776==    by 0x550F65: Perl_pp_sassign (pp_hot.c:198)
> > ==22776==    by 0x50D14D: Perl_runops_debug (dump.c:2017)
> > ==22776==    by 0x450885: S_run_body (perl.c:2282)
> > ==22776==    by 0x44FBCB: perl_run (perl.c:2208)
> > ==22776==    by 0x421435: main (perlmain.c:117)
> > ==22776==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> >
> > The call to memmove is the Move() macro here:
> >
> > /* Failed the swipe test, and it's not a shared hash key either.
> >    Have to copy the string.  */
> > STRLEN len = SvCUR(sstr);
> > SvGROW(dstr, len + 1);    /* inlined from sv_setpvn */
> > Move(SvPVX_const(sstr),SvPVX(dstr),len,char);
> > SvCUR_set(dstr, len);
> > *SvEND(dstr) = '\0';
> >
> >
> > SvPVX(dstr) is NULL - it's the "PV = 0" in this dump output:
> >
> > (gdb) call Perl_sv_dump(my_perl, dstr)
> > SV = PVNV(0xacae98) at 0xacbfd8
> >   REFCNT = 2
> >   FLAGS = (POK,pPOK)
> >   IV = 0
> >   NV = 0
> >   PV = 0
> 
> At $work, we have been seeing crashes that look like this when using
> 5.16.  Doing some more testing, and a bisect, the specific crash in
> this bug appears to have been fixed by e8c6a474e, released in 5.20.0.
> 
> Hopefully I'll be able to say the same about the crash at work if we
> switch to 5.20.
> 
> Cheers,

This was definitely not fixed, at least, not across all platforms. in 5.25.2, valgrind gives the following:

Write a string
Write an array reference
Write a new string
==43648== Invalid write of size 8
==43648==    at 0x4C2D04B: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1017)
==43648==    by 0x4F2820: Perl_sv_setsv_flags (sv.c:4726)
==43648==    by 0x6760A3A: sharedsv_scalar_store (shared.xs:792)
==43648==    by 0x6761E6F: sharedsv_elem_mg_STORE (shared.xs:983)
==43648==    by 0x4C02A5: Perl_mg_set (mg.c:277)
==43648==    by 0x4DCB22: Perl_pp_sassign (pp_hot.c:226)
==43648==    by 0x4DC2F5: Perl_runops_standard (run.c:41)
==43648==    by 0x44B3FC: S_run_body (perl.c:2521)
==43648==    by 0x44B3FC: perl_run (perl.c:2444)
==43648==    by 0x41D0BA: main (perlmain.c:123)
==43648==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==43648==
==43648==
==43648== Process terminating with default action of signal 11 (SIGSEGV)
==43648==  Access not within mapped region at address 0x0
==43648==    at 0x4C2D04B: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1017)
==43648==    by 0x4F2820: Perl_sv_setsv_flags (sv.c:4726)
==43648==    by 0x6760A3A: sharedsv_scalar_store (shared.xs:792)
==43648==    by 0x6761E6F: sharedsv_elem_mg_STORE (shared.xs:983)
==43648==    by 0x4C02A5: Perl_mg_set (mg.c:277)
==43648==    by 0x4DCB22: Perl_pp_sassign (pp_hot.c:226)
==43648==    by 0x4DC2F5: Perl_runops_standard (run.c:41)
==43648==    by 0x44B3FC: S_run_body (perl.c:2521)
==43648==    by 0x44B3FC: perl_run (perl.c:2444)
==43648==    by 0x41D0BA: main (perlmain.c:123)
==43648==  If you believe this happened as a result of a stack
==43648==  overflow in your program's main thread (unlikely but
==43648==  possible), you can try to increase the size of the
==43648==  main thread stack using the --main-stacksize= flag.
==43648==  The main thread stack size used in this run was 8388608.
==43648==
==43648== HEAP SUMMARY:
==43648==     in use at exit: 1,216,776 bytes in 4,331 blocks
==43648==   total heap usage: 11,907 allocs, 7,576 frees, 2,466,846 bytes allocated
==43648==
==43648== LEAK SUMMARY:
==43648==    definitely lost: 12 bytes in 1 blocks
==43648==    indirectly lost: 0 bytes in 0 blocks
==43648==      possibly lost: 577,798 bytes in 900 blocks
==43648==    still reachable: 638,966 bytes in 3,430 blocks
==43648==                       of which reachable via heuristic:
==43648==                         newarray           : 2,344 bytes in 74 blocks
==43648==         suppressed: 0 bytes in 0 blocks
==43648== Rerun with --leak-check=full to see details of leaked memory
==43648==
==43648== For counts of detected and suppressed errors, rerun with: -v
==43648== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault


-- 
Respectfully,
Dan Collins

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=67902



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