chris@utgard.uucp (Chris Anderson) (03/14/90)
Subject line says it all. I just compiled PL14 on our Pyramid 9825, OSx 4.4c (ucb universe), and after running 'make test', perl had failed on test "0". First problem that we've had with the standard test stuff. After running perldb on io.fs, I narrowed it down to: printf "1..22\n"; $wd = `pwd`; If you single step through the printf and $wd=`pwd`, and then run the rest of the script, everything passes. If, however, you (c)ontinue from the start, or single step through just the printf, then io.fs gets a bus error. Ran perl D14 on io.fs and it's blowing up in: open(fh,'>a') || die "Can't create a"; Any ideas? Chris -- | Chris Anderson | | QMA, Inc. email : {csusac,sactoh0}!utgard!chris | |----------------------------------------------------------------------| | My employer never listens to me, so why should he care what I say? |
chris@utgard.uucp (Chris Anderson) (03/15/90)
In article <1990Mar13.152201.19477@utgard.uucp> chris@utgard.uucp (Chris Anderson) writes: >Subject line says it all. I just compiled PL14 on our >Pyramid 9825, OSx 4.4c (ucb universe), and after running >'make test', perl had failed on test "0" in io.fs. First > problem that we've had with the standard test stuff. After reading Piet's article (about using Perl's malloc) I recompiled using Perl's malloc... it now passes all tests. Chris -- | Chris Anderson | | QMA, Inc. email : {csusac,sactoh0}!utgard!chris | |----------------------------------------------------------------------| | My employer never listens to me, so why should he care what I say? |
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (03/15/90)
In article <1990Mar13.152201.19477@utgard.uucp> chris@utgard.uucp (Chris Anderson) writes:
: Subject line says it all. I just compiled PL14 on our
: Pyramid 9825, OSx 4.4c (ucb universe), and after running
: 'make test', perl had failed on test "0". First problem
: that we've had with the standard test stuff.
:
: After running perldb on io.fs, I narrowed it down to:
:
: printf "1..22\n";
:
: $wd = `pwd`;
This is actually the same bug as the HP's have been reporting. I found
the problem--the patch that looked for VAR=value on the front of
commands to force interpretation by the shell left variable s pointing
into the middle of the string. (This is in do_exec().) Unfortunately,
the allocation of the argv right after that presumes that s is pointing
to the end of the string. Patch 15, which I will put out immediately,
will move the 3 new lines back before the matacharacter scanner.
Larry