develooper Front page | perl.perl5.porters | Postings from August 2001

Re: [ID 20010821.007] sort stupidness caused segfault

Thread Previous | Thread Next
From:
John P. Linderman
Date:
August 24, 2001 04:15
Subject:
Re: [ID 20010821.007] sort stupidness caused segfault
Message ID:
200108241114.HAA18543@raptor.research.att.com
Abigail noted
> On Wed, Aug 22, 2001 at 07:17:07AM -0400, John P. Linderman wrote:
> > > 
> > > This is a bug report for perl from root@ws.com.au,
> > > generated with the help of perlbug 1.33 running under perl v5.6.1.
> > > 
> > > 
> > > -----------------------------------------------------------------
> > > [Please enter your report here]
> > > 
> > > just stuffing around being stupid with sort {} and ..
> > > 
> > > gateway:~/tmp# cat rand
> > > #!/usr/bin/perl
> > > @a = (1, 2, 3, 4, 5, 6, 7, 8, 9);
> > > @a = sort {
> > >         @a = sort {
> > >                 @a = sort {
> > >                         @a = sort {
> > >                                 int rand (2) - 2;
> > >                         }
> > >                         int rand (2) - 2;
> > >                 }
> > >                 int rand (2) - 2;
> > >         } @a;
> > >         int rand (2) - 2;
> > > } @a;
> > > print join '', @a;
> > > gateway:~/tmp# ./rand
> > > Segmentation fault
> > 
> > I don't think this is directly related to sort because
> > a) it happens both with the 5.6 qsort and the 5.7 merge sort and
> > b) it goes away if you pass @a to the two innermost invocations
> >    (as is done on the outermost invocations) before returning the
> >    random value.
> > 
> > Still, as the documentation says,
> >    The comparison function is required to behave.
> 
> If you replace all the occurances of 'int rand (2) - 2' in the above
> code with 0, it still core dumps.
> 
> My guess is that the problem is the modification of @a during the sort.
> 
> Abigail

I agree.  If it helps those better able to understand what goes on
before the sort is called, and after the compare subroutine is called
(the core certainly isn't bloated by excessive comments :-)

Program received signal SIGSEGV, Segmentation fault.
0x080d9c9a in Perl_sv_clear (sv=0x81819a8) at sv.c:4894
4894	    	if (SvMAGIC(sv))
(gdb) where
#0  0x080d9c9a in Perl_sv_clear (sv=0x81819a8) at sv.c:4894
#1  0x080da299 in Perl_sv_free (sv=0x81819a8) at sv.c:5098
#2  0x080f8e15 in Perl_free_tmps () at scope.c:182
#3  0x080c4b4a in Perl_pp_nextstate () at pp_hot.c:40
#4  0x080c463b in Perl_runops_debug () at run.c:53
#5  0x0810c399 in sortcv (a=0x8173bd4, b=0x8173cb8) at pp_ctl.c:4183
#6  0x0810bc86 in dynprep (list1=0x81752cc, list2=0x81818c8, nmemb=9, 
    cmp=0x810c348 <sortcv>) at pp_ctl.c:3953
#7  0x0810bfb4 in S_qsortsv (list1=0x81752cc, nmemb=9, cmp=0x810c348 <sortcv>)
    at pp_ctl.c:4051
#8  0x080feced in Perl_pp_sort () at pp_ctl.c:1026
#9  0x080c463b in Perl_runops_debug () at run.c:53
#10 0x0805f92b in S_run_body (oldscope=1) at perl.c:1547
#11 0x0805f51b in perl_run (my_perl=0x8173a68) at perl.c:1469
#12 0x0805c47b in main (argc=2, argv=0xbffff8bc, env=0xbffff8c8)
    at perlmain.c:67
#13 0x40083177 in __libc_start_main (main=0x805c400 <main>, argc=2, 
    ubp_av=0xbffff8bc, init=0x805b4f0 <_init>, fini=0x8153ccc <_fini>, 
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff8b4)
    at ../sysdeps/generic/libc-start.c:129

I suspect, after the innermost invocations of sort (lacking the @a
argument to sort) cause @a to shrink, the references to the original
array elements in the outer invocation are no longer valid.

At a philosophical level (I don't know enough perlguts to determine
if it's practical), it would be nice if the array that sort is
handed could, in recent parlance, be clamped, so modifications
(except by sort, of course, which is operating outside or deep
inside the language, whichever you prefer) would cause a fatal
error (but not a coredump).  I'm unable to think of any *good*
that can come from modifications to the array being sorted as
a side-effect of the comparison routine, and I can think of
dozens of *bad* things... core dumps, limitation on the sort
implementation, increased overhead, unexpected behavior.

If the array can't be marked as read-only, I believe sortcv
could be fiddled (by someone with more experience than I)
to verify that a and b are valid references.  But that will
slow down all sorts, so it would be my second choice.  -- jpl

Thread Previous | Thread Next


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