Perl 5.7.3 test failures on Cray T90, T3E

[p5pRT]

Migrated from rt.perl.org#8837 (status was 'resolved')

Searchable as RT8837$

[p5pRT]

From kst@SDSC.EDU

I've built Perl 5.7.3 on a Cray T90 and a Cray T3E. There are a few
failures in "make test" on each machine.

I tried to run "perlbug5.7.3" on the T90, but it died with the
following error​:

Can't locate object method "tmpdir" via package "File​::Spec" at perlbug5.7.3 line 880, <> chunk 6.

I've set up a web page with the information I have so far.
It's admittedly incomplete; I have the output of "make test", but I
haven't yet re-run any of the tests in more detail. I'll try to do
that as soon as I can.

The web page is <http​://www.sdsc.edu/~kst/perl-5.7.3/>.

More info to follow.

--
Keith Thompson, San Diego Supercomputer Center kst@​sdsc.edu
<http​://www.sdsc.edu/~kst/> Office​: 858-822-0853 Fax​: 858-822-5407
Schroedinger does Shakespeare​: "To be *and* not to be"

[p5pRT]

From @schwern

On Tue, Mar 12, 2002 at 06​:52​:34PM -0800, Keith Thompson wrote​:

I've built Perl 5.7.3 on a Cray T90 and a Cray T3E. There are a few
failures in "make test" on each machine.

I tried to run "perlbug5.7.3" on the T90, but it died with the
following error​:

Can't locate object method "tmpdir" via package "File​::Spec" at
perlbug5.7.3 line 880, <> chunk 6.

That's a bit odd. Almost as if it was being run with an older version
of Perl. You don't happen to have 5.005_03 installed, do you?

I've set up a web page with the information I have so far.
It's admittedly incomplete; I have the output of "make test", but I
haven't yet re-run any of the tests in more detail. I'll try to do
that as soon as I can.

The web page is <http​://www.sdsc.edu/~kst/perl-5.7.3/>.

More info to follow.

Looks very promising!

I'm going to be perverse and ask you to try a run with ithreads. :)

--

Michael G. Schwern <schwern@​pobox.com> http​://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@​perl.org> Kwalitee Is Job One
Realize this, sweetheart, I'm squeezing my poodle.

[p5pRT]

From @jhi

Your results are pretty much in line what I've got from UNICOS/mk (T3E)
and a guy from Boeing from UNICOS (C90, I think), as listed in perldelta​:

=head2 UNICOS

../ext/Socket/socketpair.t 1 256 45 1 2.22% 12
../lib/Math/Trig.t 26 1 3.85% 25
../lib/warnings.t 460 1 0.22% 425
io/fs.t 36 1 2.78% 31
op/numconvert.t 1440 13 0.90% 208 509-510
657-658 665-666 829-830 989-990 1149-1150

=head2 UNICOS and UNICOS/mk

The io/fs test #31 is failing because in UNICOS and UNICOS/mk
truncate() cannot be used to grow the size of filehandles, only
to reduce the size. The workaround is to truncate files instead
of filehandles.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From @nwc10

On Wed, Mar 13, 2002 at 08​:14​:53PM +0200, Jarkko Hietaniemi wrote​:

Your results are pretty much in line what I've got from UNICOS/mk (T3E)
and a guy from Boeing from UNICOS (C90, I think), as listed in perldelta​:

=head2 UNICOS

../ext/Socket/socketpair.t 1 256 45 1 2.22% 12
../lib/Math/Trig.t 26 1 3.85% 25
../lib/warnings.t 460 1 0.22% 425
io/fs.t 36 1 2.78% 31
op/numconvert.t 1440 13 0.90% 208 509-510
657-658 665-666 829-830 989-990 1149-1150

IIRC numconvert passed on the crays tested by Keith Thompson.
What's the difference between them and the Boeing Cray?

=head2 UNICOS and UNICOS/mk

The io/fs test #31 is failing because in UNICOS and UNICOS/mk
truncate() cannot be used to grow the size of filehandles, only
to reduce the size. The workaround is to truncate files instead
of filehandles.

Surely the real workaround is to have perl check if the file is seekable, and
if so seek to 1 byte before the desired size, write a zero byte, then seek
back whence it came?

We could even configure test for this (at the time of ftruncate), define a
symbol, and make it fairly generic. If no-one says that's a stupid idea, I'll
give it a go. It's more fun that wondering about exp in long double Irix.

Nicholas Clark
--
Even better than the real thing​: http​://nms-cgi.sourceforge.net/

[p5pRT]

From @jhi

On Wed, Mar 13, 2002 at 08​:46​:46PM +0000, Nicholas Clark wrote​:

On Wed, Mar 13, 2002 at 08​:14​:53PM +0200, Jarkko Hietaniemi wrote​:

Your results are pretty much in line what I've got from UNICOS/mk (T3E)
and a guy from Boeing from UNICOS (C90, I think), as listed in perldelta​:

=head2 UNICOS

../ext/Socket/socketpair.t 1 256 45 1 2.22% 12
../lib/Math/Trig.t 26 1 3.85% 25
../lib/warnings.t 460 1 0.22% 425
io/fs.t 36 1 2.78% 31
op/numconvert.t 1440 13 0.90% 208 509-510
657-658 665-666 829-830 989-990 1149-1150

IIRC numconvert passed on the crays tested by Keith Thompson.
What's the difference between them and the Boeing Cray?

Different FPU​: see the warnings about incompatible fp cflags
in Keith's log.

=head2 UNICOS and UNICOS/mk

The io/fs test #31 is failing because in UNICOS and UNICOS/mk
truncate() cannot be used to grow the size of filehandles, only
to reduce the size. The workaround is to truncate files instead
of filehandles.

Surely the real workaround is to have perl check if the file is seekable, and
if so seek to 1 byte before the desired size, write a zero byte, then seek
back whence it came?

I forgot to mention that I tried exactly that, and it didn't seem to
work. Once you ftruncate, there's no getting back, it seemed.
(There's more to the mystery, I admit​: trying to replicate the failure
in trivial C does *not* work​: the ftruncate is hapy to extend a file.
But the Perl C code fails. Then I ran out of spare cycles.)

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From @jhi

On Wed, Mar 13, 2002 at 01​:26​:09PM -0800, Keith Thompson wrote​:

On Wed, Mar 13, 2002 at 10​:59​:17PM +0200, Jarkko Hietaniemi wrote​:

On Wed, Mar 13, 2002 at 08​:46​:46PM +0000, Nicholas Clark wrote​:

IIRC numconvert passed on the crays tested by Keith Thompson.
What's the difference between them and the Boeing Cray?

Different FPU​: see the warnings about incompatible fp cflags
in Keith's log.

The Boeing machine is a C90, right? That's an older machine than
our T90. (SDSC installed a C90 in 1993; it was gone by the time I
started working there in 1999.)

The T90 can have either Cray or IEEE floating-point. Ours is IEEE.
I think the C90 can only have Cray floating-point. If the numconvert

Correct.

test implicitly assumes IEEE (a valid assumption on the vast majority
of systems these days), I'm not too surprised that it failed.

BTW, our T90 is being decommissioned at the end of this month.
(I'll miss the waterfall.)

I miss the round coach/sofa of XMPs.

--
Keith Thompson, San Diego Supercomputer Center kst@​sdsc.edu
<http​://www.sdsc.edu/~kst/> Office​: 858-822-0853 Fax​: 858-822-5407
Schroedinger does Shakespeare​: "To be *and* not to be"

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From @nwc10

On Wed, Mar 13, 2002 at 10​:59​:17PM +0200, Jarkko Hietaniemi wrote​:

On Wed, Mar 13, 2002 at 08​:46​:46PM +0000, Nicholas Clark wrote​:

Surely the real workaround is to have perl check if the file is seekable, and
if so seek to 1 byte before the desired size, write a zero byte, then seek
back whence it came?

I forgot to mention that I tried exactly that, and it didn't seem to
work. Once you ftruncate, there's no getting back, it seemed.
(There's more to the mystery, I admit​: trying to replicate the failure
in trivial C does *not* work​: the ftruncate is hapy to extend a file.
But the Perl C code fails. Then I ran out of spare cycles.)

Ah. One of those.
We had a similar one where perl doing DNS lookup for a particular host with
dozens of A records (or something like that) SEGVed the FreeBSD libc
resolver code, but trying to write the same thing in C (to bug report it)
just didn't work.

Maybe the simple C programs don't have enough undefined behaviour else where,
but perl has so much that some leaks through to make the repeatable things
go wrong.

And I don't even have a cray to test on. :-(

Nicholas Clark
--
Even better than the real thing​: http​://nms-cgi.sourceforge.net/

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed, Mar 13, 2002 at 10​:59​:17PM +0200, Jarkko Hietaniemi wrote​:

On Wed, Mar 13, 2002 at 08​:46​:46PM +0000, Nicholas Clark wrote​:

IIRC numconvert passed on the crays tested by Keith Thompson.
What's the difference between them and the Boeing Cray?

Different FPU​: see the warnings about incompatible fp cflags
in Keith's log.

The Boeing machine is a C90, right? That's an older machine than
our T90. (SDSC installed a C90 in 1993; it was gone by the time I
started working there in 1999.)

The T90 can have either Cray or IEEE floating-point. Ours is IEEE.
I think the C90 can only have Cray floating-point. If the numconvert
test implicitly assumes IEEE (a valid assumption on the vast majority
of systems these days), I'm not too surprised that it failed.

BTW, our T90 is being decommissioned at the end of this month.
(I'll miss the waterfall.)

--
Keith Thompson, San Diego Supercomputer Center kst@​sdsc.edu
<http​://www.sdsc.edu/~kst/> Office​: 858-822-0853 Fax​: 858-822-5407
Schroedinger does Shakespeare​: "To be *and* not to be"

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed, Mar 13, 2002 at 08​:14​:53PM +0200, Jarkko Hietaniemi wrote​:
[...]

=head2 UNICOS and UNICOS/mk

The io/fs test #31 is failing because in UNICOS and UNICOS/mk
truncate() cannot be used to grow the size of filehandles, only
to reduce the size. The workaround is to truncate files instead
of filehandles.

I just tried a quick experiment, and it appears that truncate() and
ftruncate() can be used to grow files and filehandles, respectively,
on both the T90 and the T3E. (It may be different on the J90,
which is likely running an older version of UNICOS.) On the T3E,
the new portion of the file is filled with '\0's; on the T90, it's
filled with garbage.

The man page doesn't specifically say anything about the behavior
of truncate() or ftruncate() when the specified size is greater than
the current size of the file. It does say this​:

  These are compatibility functions, which are provided to aid in the
  porting of code from other systems. They are implemented through a
  combination of open(2), lseek(2), and trunc(2) system calls.

--
Keith Thompson, San Diego Supercomputer Center kst@​sdsc.edu
<http​://www.sdsc.edu/~kst/> Office​: 858-822-0853 Fax​: 858-822-5407
Schroedinger does Shakespeare​: "To be *and* not to be"

[p5pRT]

From @jkeenan

On Wed Mar 13 09​:09​:40 2002, RT_System wrote​:

On Wed, Mar 13, 2002 at 08​:14​:53PM +0200, Jarkko Hietaniemi wrote​:
[...]

=head2 UNICOS and UNICOS/mk

The io/fs test #31 is failing because in UNICOS and UNICOS/mk
truncate() cannot be used to grow the size of filehandles, only
to reduce the size. The workaround is to truncate files instead
of filehandles.

I just tried a quick experiment, and it appears that truncate() and
ftruncate() can be used to grow files and filehandles, respectively,
on both the T90 and the T3E. (It may be different on the J90,
which is likely running an older version of UNICOS.) On the T3E,
the new portion of the file is filled with '\0's; on the T90, it's
filled with garbage.

The man page doesn't specifically say anything about the behavior
of truncate() or ftruncate() when the specified size is greater than
the current size of the file. It does say this​:

 These are compatibility functions\, which are provided to aid in the
 porting of code from other systems\.  They are implemented through a
 combination of open\(2\)\, lseek\(2\)\, and trunc\(2\) system calls\.

There has been no correspondence in this RT for more than eleven years.

Is there anyone with access to Cray who could comment on how more recent Perls do on that platform?

Thank you very much.
Jim Keenan

[p5pRT]

From greg@blekko.com

On Sun, Dec 15, 2013 at 06​:37​:53PM -0800, James E Keenan via RT wrote​:

There has been no correspondence in this RT for more than eleven years.

Is there anyone with access to Cray who could comment on how more recent Perls do on that platform?

The platform discussed, UNICOS and UNICOS/mk, is no longer active. It
was last used on the Cray T3E, which was sold from 1995-2001.

The more recent UNICOS/lc or CLE is based on SUSE Linux (on the
service nodes.) and a cut-down Linux kernel (on the compute nodes.)

-- greg

[p5pRT]

From @jkeenan

On Sun Dec 15 21​:39​:59 2013, greg@​blekko.com wrote​:

On Sun, Dec 15, 2013 at 06​:37​:53PM -0800, James E Keenan via RT wrote​:

There has been no correspondence in this RT for more than eleven
years.

Is there anyone with access to Cray who could comment on how more
recent Perls do on that platform?

The platform discussed, UNICOS and UNICOS/mk, is no longer active. It
was last used on the Cray T3E, which was sold from 1995-2001.

The more recent UNICOS/lc or CLE is based on SUSE Linux (on the
service nodes.) and a cut-down Linux kernel (on the compute nodes.)

-- greg

Closing ticket. If you run into problems building Perl on the more recent platform, please file new ticket.

Thank you very much.
Jim Keenan

[p5pRT]

@jkeenan - Status changed from 'open' to 'resolved'