Skip Menu |
Report information

Subject: 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Mon, 2 Nov 2009 16:51:36 +0000
To: perlbug [...] perl.org
From: Ævar Arnfjörð Bjarmason <avarab [...] gmail.com>
Download (untitled) / with headers
text/plain 995b
See the thread on p5p discussing this bug: http://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg152347.html When I upgraded from 5.10.0 -> 5.10.1 I discovered a regression in perl that I traced back to this commit. The code in question can be reduced to: perl -e 'my $x = get_x(); my %x = %$x; sub get_x { %x=(1..1000); return \%x; }' panic: attempt to copy freed scalar 253a860 to 2534880 at -e line 1. On my system it just does that for sufficiently large values of 1..1000. If I change that to 1..10 it doesn't panic but C<my %x> ends up being: (1 => undef, 3 => undef, 5 => undef, 7 => undef, 9 => undef) While on 5.10.0 it's the correct: (1 => 2, 3 => 4, 5 => 6, 7 => 8, 9 => 10) On other perl versions (asking around in #p5p) the results have been: * 5.8.8 segfaults * 5.8.9 relpanic * 5.10.1 relpanic * 5.10.0 works fine * 5.11.0 relpanic Here's an overview of what might be wrong: http://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg152369.html
Subject: Re: [perl #70171] 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Tue, 3 Nov 2009 10:17:00 -0600
To: perl5-porters [...] perl.org
From: Brad Gilbert <b2gills [...] gmail.com>
Download (untitled) / with headers
text/plain 1.5k
On Mon, Nov 2, 2009 at 10:52 AM, Ãvar Arnfjörð Bjarmason <perlbug-followup@perl.org> wrote: Show quoted text
> # New Ticket Created by  "Ævar Arnfjörð Bjarmason" > # Please include the string:  [perl #70171] > # in the subject line of all future correspondence about this issue. > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=70171 > > > > See the thread on p5p discussing this bug: > http://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg152347.html > > When I upgraded from 5.10.0 -> 5.10.1 I discovered a regression in > perl that I traced back to this commit. The code in question can be > reduced to: > >  perl -e 'my $x = get_x(); my %x = %$x; sub get_x { %x=(1..1000); > return \%x; }' >  panic: attempt to copy freed scalar 253a860 to 2534880 at -e line 1. > > On my system it just does that for sufficiently large values of > 1..1000. If I change that to 1..10 it doesn't panic but C<my %x> ends > up being: > >    (1 => undef, 3 => undef, 5 => undef, 7 => undef, 9 => undef) > > While on 5.10.0 it's the correct: > >    (1 => 2, 3 => 4, 5 => 6, 7 => 8, 9 => 10) > > On other perl versions (asking around in #p5p) the results have been: >  * 5.8.8 segfaults >  * 5.8.9 relpanic >  * 5.10.1 relpanic >  * 5.10.0 works fine >  * 5.11.0 relpanic > > Here's an overview of what might be wrong: > http://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg152369.html > >
What happens when you run perl -Mstrict -we 'my $x = get_x(); my %x = %$x; sub get_x { %x=(1..1000); return \%x; }' on those systems?
CC: perl5-porters [...] perl.org
Subject: Re: [perl #70171] 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Tue, 3 Nov 2009 20:20:28 +0000
To: Brad Gilbert <b2gills [...] gmail.com>
From: Ævar Arnfjörð Bjarmason <avarab [...] gmail.com>
Download (untitled) / with headers
text/plain 336b
On Tue, Nov 3, 2009 at 4:17 PM, Brad Gilbert <b2gills@gmail.com> wrote: Show quoted text
> What happens when you run > > perl -Mstrict -we 'my $x = get_x(); my %x = %$x; sub get_x { > %x=(1..1000); return \%x; }' > > on those systems?
The exact same thing (although I've only tested under 5.10.1). Strictures have nothing to do with why this happens.
Subject: Re: [perl #70171] 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Sun, 6 Dec 2009 13:37:39 -0800
To: perl5-porters [...] perl.org
From: Father Chrysostomos <sprout [...] cpan.org>
Download (untitled) / with headers
text/plain 595b
In this case my %x = %$x assigns a hash to itself. This causes the hv_clear in pp_aassign to wipe away the hash before it can be copied. The ‘panic: attempt to copy freed scalar’ error is triggered by this line, which copies the value: sv_setsv(tmpstr,*relem); /* value */ The solution is to make sure the OPpASSIGN_COMMON flag is on in such cases, so that pp_aassign copies everything before doing the assignment. This fix causes a bus error in sort.t, because it happens to expose bug #71076. If the patch in that queue is applied first, this one works with no problems.
Download open_VZdDQQsA.txt
text/plain 1.2k

Message body is not shown because sender requested not to inline it.

CC: perl5-porters [...] perl.org
Subject: Re: [perl #70171] 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Mon, 7 Dec 2009 14:35:09 +0100
To: Father Chrysostomos <sprout [...] cpan.org>
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
Download (untitled) / with headers
text/plain 805b
2009/12/6 Father Chrysostomos <sprout@cpan.org>: Show quoted text
> In this case my %x = %$x assigns a hash to itself. This causes the hv_clear > in pp_aassign to wipe away the hash before it can be copied. The ‘panic: > attempt to copy freed scalar’ error is triggered by this line, which copies > the value: >                        sv_setsv(tmpstr,*relem);        /* value */ > > The solution is to make sure the OPpASSIGN_COMMON flag is on in such cases, > so that pp_aassign copies everything before doing the assignment.
Even if you have an OP_PADSV on the left ? I think that in this case we can leave the optimisation in. Show quoted text
> This fix causes a bus error in sort.t, because it happens to expose bug > #71076. If the patch in that queue is applied first, this one works with no > problems.
Ok.
Subject: Re: [perl #70171] 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Mon, 14 Dec 2009 16:31:17 +0100
To: Father Chrysostomos <sprout [...] cpan.org>, Perl 5 Porters <perl5-porters [...] perl.org>
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
2009/12/13 Father Chrysostomos <sprout@cpan.org>: Show quoted text
> > On Dec 7, 2009, at 5:35 AM, Rafael Garcia-Suarez wrote: >
>> 2009/12/6 Father Chrysostomos <sprout@cpan.org>:
>>> >>> In this case my %x = %$x assigns a hash to itself. This causes the >>> hv_clear >>> in pp_aassign to wipe away the hash before it can be copied. The ‘panic: >>> attempt to copy freed scalar’ error is triggered by this line, which >>> copies >>> the value: >>>                       sv_setsv(tmpstr,*relem);        /* value */ >>> >>> The solution is to make sure the OPpASSIGN_COMMON flag is on in such >>> cases, >>> so that pp_aassign copies everything before doing the assignment.
>> >> Even if you have an OP_PADSV on the left ? I think that in this case >> we can leave the optimisation in.
> > The optimisation disabled by OPpASSIGN_COMMON is still enabled for OP_PADSV > with this patch, but the maybe_common_vars optimisation is not, so attached > is a replacement patch.
Thanks, applied to bleadperl as 0f907b96d618c97cd2e020841a70ae037954a616.
CC: Father Chrysostomos <sprout [...] cpan.org>, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #70171] 5.10.0 -> 5.10.1 Regression in fafafbaf70 (Big slowdown in 5.10 @_ parameter passing)
Date: Tue, 16 Feb 2010 16:47:53 +0000
To: Rafael Garcia-Suarez <rgs [...] consttype.org>
From: Ævar Arnfjörð Bjarmason <avarab [...] gmail.com>
Download (untitled) / with headers
text/plain 1.3k
On Mon, Dec 14, 2009 at 15:31, Rafael Garcia-Suarez <rgs@consttype.org> wrote: Show quoted text
> 2009/12/13 Father Chrysostomos <sprout@cpan.org>:
>> >> On Dec 7, 2009, at 5:35 AM, Rafael Garcia-Suarez wrote: >>
>>> 2009/12/6 Father Chrysostomos <sprout@cpan.org>:
>>>> >>>> In this case my %x = %$x assigns a hash to itself. This causes the >>>> hv_clear >>>> in pp_aassign to wipe away the hash before it can be copied. The ‘panic: >>>> attempt to copy freed scalar’ error is triggered by this line, which >>>> copies >>>> the value: >>>>                       sv_setsv(tmpstr,*relem);        /* value */ >>>> >>>> The solution is to make sure the OPpASSIGN_COMMON flag is on in such >>>> cases, >>>> so that pp_aassign copies everything before doing the assignment.
>>> >>> Even if you have an OP_PADSV on the left ? I think that in this case >>> we can leave the optimisation in.
>> >> The optimisation disabled by OPpASSIGN_COMMON is still enabled for OP_PADSV >> with this patch, but the maybe_common_vars optimisation is not, so attached >> is a replacement patch.
> > Thanks, applied to bleadperl as 0f907b96d618c97cd2e020841a70ae037954a616.
I added one extra test to that for good measure: http://github.com/avar/perl/commit/26b110cf2c6fe8d8bb6ba625b0905c60392255ee It can be pulled from the rt-70171-extra-test branch on git://github.com/avar/perl.git


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org