Front page | perl.vmsperl |
Postings from June 2002
RE: possible VMS v5.5 fix (was RE: 5.8.0 release candidate status)
From:
Craig A. Berry
Date:
June 15, 2002 16:27
Subject:
RE: possible VMS v5.5 fix (was RE: 5.8.0 release candidate status)
Message ID:
a05111b14b9315916fcb0@[172.16.52.1]
At 6:21 PM -0400 6/14/02, Henry A. Frystak - System Manager wrote:
>
>The compile on the VAX 5.5-2 machine was clean (although it took a VERY long
>time), so I went into the MMS TEST phase. Well, more bad news. It failed on:
>
>t/io/fs..............................FAILED at test 31
>t/io/open............................FAILED at test 36
>
>and then hung on test t/io/openpid (after an hour, I gave up and ctrl-Y'd out).
>Upon running separately:
.. . .
>ok 8 - killing procs 2 & 3
># waiting for process 539145024 to exit
> (After waiting for at least 3 minutes-last time 60)
> Interrupt
Hmm. I'm not sure how to debug this remotely but will have a look at
the test and see if I can think of anything we can try.
>Since I don't know how to pick up running the standard test suite after the
>t/io/openpid test, I had to quit here.
You'd probably have to modify the test to skip the one that fails.
>On seeing the report of a new snapshot, I got brave and downloaded it to my
>OpenVMS AXP V7.1-1H2 machine.
>Unfortunately, this latest snapshot did nothing to help my situation; the same
>8 failures as reported before are still there.
>
>>t/io/fs..............................FAILED at test 31
>>t/op/stat............................FAILED at test 29
>>ext/Cwd/t/cwd........................FAILED at test 9
>>lib/AutoSplit........................FAILED at test 2
>>lib/ExtUtils/t/Command...............FAILED at test 10
>>lib/File/stat........................FAILED at test 18
>>lib/Net/hostent......................FAILED at test 5
>>t/pod/find...........................FAILED at test 2
>>
> >Failed 8 test scripts out of 628, 98.73% okay.
>Upon seeing Larry Bohan's message about a proposed fix for t/io/fs ,
>I feel this is right on. The comment "# must have delete access to rename a
>directory" is definitely true on VMS; why was this left out of the patches?
The code Larry posted is actually already in the test and I believe
has been for a long time. I think what may be happening is that set
file/prot=o:d doesn't work because the process running the test is
not the owner of the directory whose access is being changed. Either
the protection change is failing or the change succeeds but the
rename fails because the owner has access but the current process is
not the owner. I'm afraid running the test suite on a [.perl...]
tree you are not the owner of just isn't going to work. It's my
fault for not documenting this better (well, at all); I'll try to
rectify that ASAP, but see below.
>His comments about t/op/stat and "the [perl...] tree not owned by the
>user/account I was doing the make/test/install from" may also be true, even
>though I am running this from my priv account.
Your authorized privs will do you no good. Recently I added some
logic to [.vms]test.com that downgrades privs to only NETMBX,TMPMBX
for the run of the test suite, and then when it's done restores privs
to whatever they were beforehand. It became clear to me that the
tests really need to be run as much as possible in a private sandbox
where the opportunity for causing system-wide mayhem is eliminated.
There are just too many things that can go wrong in a scary way,
particularly related to logical names. For example, if you tell a
UNIX programmer that deleting an environment variable on VMS doesn't
guarantee that it's no longer visible because the environment has
layers, he may put in something like:
1 while delete $ENV{PATH};
which, when it's done deleting the PATH logical name from your
process, job, and group tables, will also delete it from your system
table if you have the privs to do so. Also, there are modules like
File::Find that iterate over the pieces of a path name and if one of
the pieces clashes with a logical name you end up way off course.
For example, if you search for [foo.sys.bar]*.dat and you have
logical name SYS defined, pointing to, say SYS$LIBRARY, then at some
point it ends up looking for SYS$LIBRARY:BAR.DIR. Usually this
causes failure but no harm; however, best to be safe.
There is no way to guarantee things like the above won't creep into
the test suite despite our best efforts, so it seemed the only
rational thing was to contain the test suite in a sandbox using the
trusty privilege mechanism. The part I hadn't thought through (or
documented) was that you have to be the owner of the sandbox for this
to work.
Can anyone seeing the same failures that Henry was seeing try running
the tests from the same account that unpacked the archive?
>Well, as hinted in my previous message, the little red "Time Expired" flag
>has gone up on my TUIT meter. When I get back from my vacation, if time
>permits, I will re-join the forray into the snapshot/RC hunt. I desparately
>would like a more recent Perl version for the VAX 5.5-2 system (currently
>running version 5.004_04); I've had trouble trying to build 5.005_03 or
>anything newer on this system. At least the new building procedures have
>made building that much easier. Thanks, everyone, for all your help.
Have a nice vacation and thanks for your help in testing.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser