[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

Re: [perl #59456] Perl 5.8.8 Build Failures for SunOS 4.1.3



On Mon, Sep 29, 2008 at 01:48:23PM -0700, Peterson, Bob D (MN14) wrote:

> We need a relatively new version of perl running on "SunOS cxh 4.1.3_U1
> 3 sun4m". We can't upgrade the OS because of frozen vendor software. I

Gosh. That's rather frozen.
Whilst Perl 5.000 was first developed on SunOS, I don't know if anyone
has tried to build it there recently.

> I'm not experienced with large scale builds like this, but I thought I
> would try it anyways. The compiler used was "gcc".
> 
> The build itself went okay (quite a few "implicit function declaration"
> warnings) but some of the tests are failing. To the inexperienced eye,
> it looks like the most troublesome problem is the "lib/sort" test. I
> expect that we'll be using sort extensively.

Yes. That looks like a potential problem.

> I'm not sure what's up with the "make" failures at the end ("_test_tty",
> etc.). Is that a consequence of the test failures?

Yes (I think so). It's one of the targets in the makefile that it recurses to.

> I wasn't able to use "perlbug" because the workstation is behind a
> firewall and can't send and receive e-mail messages.

perlbug can actually save its output to a file, instead of mailing it directly.

The output of running ./myconfig in the build tree would be useful, along
with that of gcc -v

> > ./perl ext/List/Util/t/shuffle.t
> 1..6
> ok 1 - no args
> ok 2 - 1 in 1 out
> ok 3 - one arg
> Segmentation fault

A stack backtrace of that one might show something interesting.

> I edited the test script to report the value of $oldaction->{FLAGS},
> and it reported the value 2. This appears to correspond to SA_INTERRUPT,
> which is described as "do not restart system on signal return".

Useful. The test itself is:

if($oldaction->{FLAGS}) {
    if ($^O eq 'linux' || $^O eq 'unicos') {
	print "ok 6 # Skip: sigaction() thinks different in $^O\n";
    } else {
	print "not ok 6\n";
    }
} else {
    print "ok 6\n";
}

I checked on Linux - the value returned there (at least for me) is SA_NODEFER
so it looks like that test should also be a skip on SunOS (4)

What is the value of $^O on SunOS 4? (And for that matter on SunOS 5 - I don't
have access to anything Solaris any more)

> > ./perl ext/Socket/t/socketpair.t
> 1..45

> ok 10 - shutdown left for writing
> EOF on right took over 3 seconds at ext/Socket/t/socketpair.t line 119.
> Something unexpectedly hung during testing at ext/Socket/t/socketpair.t
> line 39.

That should probably be a skip.

> ============================================
> > ./perl lib/Memoize/t/speed.t
> 1..6
> # fib(20) took 2 seconds.
> # OK, N=24 ought to do it.
> # OK, fib(24) was slow enough; it took 11 seconds.
> # Total calls: 150049.
> ok 1
> ok 2
> ok 3
> ok 4
> ok 5
> ok 6
> 
> Interesting. This time it didn't fail.

Some of the timing related tests are a bit fickle, but not usually that one.

> ============================================
> > ./perl lib/sort.t
> 1..119
> ok 1 - order ok for size 0
> ok 2 - contents ok for size 0
> ok 3 - order ok for size 1
> ok 4 - contents ok for size 1
> ok 5 - order ok for size 2
> ok 6 - contents ok for size 2
> ...
> ok 27 - order ok for size 6463
> ok 28 - contents ok for size 6463
> ok 29 - sort::current for _qsort
> ok 30 - order ok for size 0
> ok 31 - contents ok for size 0
> ok 32 - order ok for size 1
> ok 33 - contents ok for size 1
> ...
> ok 46 - order ok for size 139
> ok 47 - contents ok for size 139
> Segmentation fault
> 
> I tried to use the debugger to locate the point where it crashes. The
> debugger seemed to lose its mind the second time 'main' was called, at
> line 147. It couldn't list lines, breaks were ineffective, etc. This
> second call is when the crash occurs, and appears to invoke the
> "quicksort" algorithm.

Perl debugger or C debugger?

> Instead of using the debugger, I put in diagnostic messages and it
> appears that the 'sort' at line 111 is where it crashes. It's this
> statement:
> 	@sorted = sort { substr($a, 0, $RootWidth)
> 				    cmp
> 	                 substr($b, 0, $RootWidth) } @$unsorted;
> It occurs when the array size is 300.

Unfortunately that doesn't ring any bells with me. If you recompile with -O1
or -O0 (rather than -O2, which I'm guessing was the default) does it work?
You might be able to get away with just deleting pp_sort.o and re-running
make. (worth trying before rebuilding all the object files


> ============================================
> >./perl lib/Tie/File/t/09_gen_rs.t
> 1..59
> ok 1
> ok 2
> ...
> ok 49
> ok 50
> (more than a 1 hour delay here)
> Out of memory during "large" request for 33558528 bytes, total sbrk() is
> 85576088 bytes at /usr/local/lib/perl5/site_perl/5.8.8/Tie/File.pm line
> 895, <$fh> line 4195326.

This doesn't ring any bells.

Nicholas Clark


Follow-Ups from:
Andy Dougherty <doughera@lafayette.edu>

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]