Skip Menu |
Queue is disabled
This queue is disabled and you may not create new tickets in it. Disabled queues are usually because the distribution was merged with another or changed names. Sometimes they are the end result of a bad autocreate from PAUSE data before anyone noticed.
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