die inside sort comparitor causes SV error #15243
Comments
From @jimavThis is a bug report for perl from jim.avera@gmail.com, If die is called inside a sort comparitor function, errors like the Attempt to free unreferenced scalar: SV 0x12c7458, Perl interpreter: 0x12a2010 at (location of die) #!/usr/bin/perl my @data = ( ["A"], ["B"], ["C"] ); @data = die "Die in sort comparator" if $aval eq "C"; return ($aval cmp $bval); # Die in sort comparator at /tmp/test.pl line 11. Flags: Site configuration information for perl 5.20.2: Configured by Debian Project at Tue Mar 1 16:51:39 UTC 2016. Summary of my perl5 (revision 5 version 20 subversion 2) configuration: Locally applied patches: @INC for perl 5.20.2: Environment for perl 5.20.2: |
From @dcollinsnConfirmed in blead. ** VALGRIND ** Die in sort comparator at 127759.pl line 11. |
From [Unknown Contact. See original ticket]Confirmed in blead. ** VALGRIND ** Die in sort comparator at 127759.pl line 11. |
From @iabynOn Mon, Mar 21, 2016 at 03:20:31PM -0700, via RT wrote:
This is an interaction between sort's 'in place' optimisation, and perl's In something like @a = sort {...} @a, The merge sort code is a bit impenetrable, so I'm unsure as yet of the -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgDave Mitchell wrote:
Even if random rubbish were not there, this implies another bad -zefram |
From @cpansproutOn Tue Jun 07 12:48:51 2016, zefram@fysh.org wrote:
Is it really a win if we disable an optimisation that helps more often than it hinders? Currently, the array is made read-only to prevent it from being written too. That change was made in response to a bug report, in which some code *accidentally* overwrote the array, due to a programming error. I do like making things correct, but not at the cost of slowing down correct code that would not suffer from the bugs fixed (though I am not always consistent:-). Is a compromise possible? -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
The dilemma is cause for us to lament how unsuited to optimisation Some of the win from in-place optimisation, I suspect most of it, comes If that doesn't satisfactorily win, then we get to agonise again about the -zefram |
From @maukeAm 07.06.2016 um 22:16 schrieb Zefram:
If one of the array elements is an object that uses overloading but "detectably innocuous" may not exist in Perl. -- |
From gm@qwurx.deFrom the keyboard of Zefram [07.06.16,21:16]:
Even for the trivial case of { $a <=> $b }, the compiler would have to So, the optimizer would have to check the complete code path which could
0--gg- -- |
From @ikegamiOn Tue, Jun 7, 2016 at 4:16 PM, Zefram <zefram@fysh.org> wrote:
Those aren't necessarily innocuous because of magic scalars and overloaded |
From @cpansproutOn Wed Jun 08 11:06:18 2016, ikegami@adaelis.com wrote:
Note that pp_sort already looks for magic and overloading at the outset and follows different code paths accordingly. -- Father Chrysostomos |
From @iabynOn Wed, Jun 08, 2016 at 01:13:10PM -0700, Father Chrysostomos via RT wrote:
Now (mostly) fixed by v5.25.3-188-g84721d6. -- |
|
@iabyn - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.26.0, this and 210 other issues have been Perl 5.26.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#127759 (status was 'resolved')
Searchable as RT127759$
The text was updated successfully, but these errors were encountered: