New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sort with custom subname and prototype ($$) segfaults intermittently #8478
Comments
From johnh@isi.eduCreated by johnh@isi.eduFor a long time (more than a year), perl has segfaulted for me in a ---------------------------------------- @scores = ( @match_indices = (0,1,2,3); It segfaults for me on the last line, both with perl 5.8.8 on fedora Here's the backtrace on 5.8.8 built with debugging: (gdb) run -Ilib /tmp/t.pl Program received signal SIGSEGV, Segmentation fault. The test program is 100% repeatable. I extracted it from a larger For a different input I got a different traceback: Program received signal SIGSEGV, Segmentation fault. (I didn't isolate this to a test kernel.) Any suggestions? Thanks, Perl Info
|
From @TuxOn Thu, 08 Jun 2006 21:23:41 -0700, "johnh@isi.edu (via RT)"
It has changed in devel: pc09:/pro/3gl/CPAN/perl-current 105 > ./perl -Ilib ~/test.pl
-- |
The RT System itself - Status changed from 'new' to 'open' |
From @tamiasOn Thu, Jun 08, 2006 at 09:23:41PM -0700, johnh @ isi. edu wrote:
I get a segfault in 5.8.7, but it works fine in 5.8.3. Ronald |
From @rgsjohnh@isi.edu (via RT) wrote:
I don't understand the algorithm, but making a copy of @match_indices Also, the $$ is necessary for this problem. Might be related to some |
From johnh@isi.eduOn Fri, 09 Jun 2006 08:59:10 PDT, "Rafael Garcia-Suarez via RT" wrote:
the ($$) is not required. I get the same segfault with: sub sort_by_index { (on perl-5.8.8 / fedora core 5). -John |
From johnh@isi.eduOn Fri, 09 Jun 2006 08:49:56 PDT, "Ronald J Kimball via RT" wrote:
For me, the bug was inconsistent. Depending on the arguments passed A colleague of mine pointed out that there are two bugs here: It actually has a mistaken double indirection. The subroutine should sub sort_by_index($$) { Fixing bug #2, which conincidently makes the segfault go away for me. I'll leave the original code and bug #1 to you folks, since I don't -John |
From @gbarrOn Fri, June 9, 2006 10:59 am, Rafael Garcia-Suarez wrote:
That because sort is modifying @match_indices as it goes because it Simply assigning to a different array also solves it. Try adding warn join(",",@match_indices); into sort_by_index and see what It would seem that when doing sort in-place that the array is at times in Graham. |
From @salvaRafael Garcia-Suarez wrote:
This is probably related to @data = sort compare @data; being optimized into sort_inplace compare @data; that causes @data to be in an inconsistent state when accessed from The solution may be to remove the optimization or to disallow access to Cheers, - Salva |
From @iabynOn Sat, Jun 10, 2006 at 09:33:08AM +0200, Salvador Fandiño wrote:
Yes, the mergesort stores temporary (non-SV) pointers in the SV** array I think the fix is to, in the presence of a sort function, memcopy the Note that this is still a lot more efficient than the unoptimised I'll fix this when I get some time. -- |
From david@landgren.netJohn Heidemann wrote:
Agreed.
I would also lose the prototypes, and the assignment from @_ to $A and I can't think of any reason off-hand why one would want to remove this David |
From @ysthOn Sun, Jun 11, 2006 at 10:26:23PM +0200, David Landgren wrote:
Where the sort_by_index resides in a different package. |
From jpl@research.att.comDavid Landgren <david@landgren.net> replied to John Heidemann <johnh@isi.edu>:
Bug 1 trumps bug 2. During the sort, there's a second, This may have crept in with the in-place optimization, It might be possible to fix this by keeping the If possible, it would seem best to disallow references |
From jpl@research.att.comDave Mitchell <davem@iabyn.com> offered
Would it be possible to use magic to disable access to the array |
From @hvds"John P. Linderman" <jpl@research.att.com> wrote: But "in-place sorting with @x = sort @x" is an optimisation, and as such :It might be possible to fix this by keeping the I doubt we can detect them (since they may occur via aliasing etc), Hugo |
From @iabynOn Mon, Jun 12, 2006 at 05:38:31PM +0100, hv@crypt.org wrote:
I think my suggestion of the partial pessimistion of memcopying AvARRAY -- |
p5p@spam.wizbit.be - Status changed from 'open' to 'stalled' |
From @cpansproutOn Thu Jun 08 21:23:40 2006, johnh@isi.edu wrote:
This gives me: d963bf0, three commits later (the but I can’t see how it fixes it. |
From [Unknown Contact. See original ticket]On Thu Jun 08 21:23:40 2006, johnh@isi.edu wrote:
This gives me: d963bf0, three commits later (the but I can’t see how it fixes it. |
@cpansprout - Status changed from 'stalled' to 'open' |
From @dcollinsnSome research into the history of this testcase: Until 5.11.5, this was fine on the perls I'm able to build. In 5.11.5, it started throwing a segfault, in 5.13.4 this became a libc "aborted", in 5.17.10, it segfaulted again, and in 5.19.1, 5.19.3, and all later versions, it is fine EXCEPT for -thread-multi-debug builds, which still amazingly manage to kill libc: *** Error in `perl5.25.2-thread-multi-debug': free(): invalid next size (fast): 0x0000000000b1cd80 *** Valgrind is very disappointed: ==37049== Invalid read of size 4 Valgrind is equally disappointed for normal builds of 5.25.2, but they manage to avoid crashing through some stroke of luck. The valgrind errors are the same. This looks to me like a sign of either modifying a value that is on the context stack, or modifying an array that is in the process of being sort()ed in-place. If the former, then this is a dependency of 77706. If the latter - I vaguely remember another ticket about modifying an array while it is being sorted, this is probably similar. There's some discussion at RT #127759 on that topic. |
From [Unknown Contact. See original ticket]Some research into the history of this testcase: Until 5.11.5, this was fine on the perls I'm able to build. In 5.11.5, it started throwing a segfault, in 5.13.4 this became a libc "aborted", in 5.17.10, it segfaulted again, and in 5.19.1, 5.19.3, and all later versions, it is fine EXCEPT for -thread-multi-debug builds, which still amazingly manage to kill libc: *** Error in `perl5.25.2-thread-multi-debug': free(): invalid next size (fast): 0x0000000000b1cd80 *** Valgrind is very disappointed: ==37049== Invalid read of size 4 Valgrind is equally disappointed for normal builds of 5.25.2, but they manage to avoid crashing through some stroke of luck. The valgrind errors are the same. This looks to me like a sign of either modifying a value that is on the context stack, or modifying an array that is in the process of being sort()ed in-place. If the former, then this is a dependency of 77706. If the latter - I vaguely remember another ticket about modifying an array while it is being sorted, this is probably similar. There's some discussion at RT #127759 on that topic. |
From @iabynOn Sun, Sep 26, 2010 at 02:39:49PM -0700, Father Chrysostomos via RT wrote:
Fixed now in blead by the following. The issue was as the bit below about commit 84721d6 Partially pessimise in-place sorting -- |
From @khwilliamsonOn 08/10/2016 09:36 AM, Dave Mitchell wrote:
blead is failing to compile for me unless I revert this, with the message: pp_sort.c: In function ‘OP* Perl_pp_sort(PerlInterpreter*)’: |
From @khwilliamsonOn 08/10/2016 11:48 AM, Karl Williamson wrote:
It does compile with some options. Attached is a diff with, the options |
From @khwilliamson6c6
8c8
12,13c12,13
16c16
20,23c20,23
40,41c40,41
44c44
47c47
49c49
63c63
67a68
69c70
73a75
74a77
77a81
80a85
86a92
88a95
|
From @cpansproutOn Wed Aug 10 10:49:29 2016, public@khwilliamson.com wrote:
Fixed in ff859a7. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'pending release' |
From @jplinderman#!/usr/bin/perl -w This could be "fixed" at the expense of allocating *two* extra arrays |
From @iabynOn Wed, Aug 10, 2016 at 05:03:28PM -0400, John P. Linderman wrote:
I don't understand any of the above sentence. Its just been fixed, so why
In this code: @a = sort {...} @a at the logical perl level, a list is created from the contents of @a, The internal quicksort and mergesort implementations sort a (C) array
The previous code temporarily marked the array as readonly, which stopped something = sort { ... } @a that accessing @a during the sort would be an error. -- |
From @jplindermanI think we are in violent agreement. As you noted, long ago the internal What I meant to say is that changes could have been made to the sort The other point I was trying to make is that access to the SV pointers that $match_indices[$A] is simply $A, and would have been better written as such. If that In (not so very) short, comparison routines that reference the array that On Thu, Aug 11, 2016 at 4:11 AM, Dave Mitchell <davem@iabyn.com> wrote:
|
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#39358 (status was 'resolved')
Searchable as RT39358$
The text was updated successfully, but these errors were encountered: