rfinch@caldwr.UUCP (Ralph Finch) (09/06/89)
I'm running SunOS 4.0.1 on a Sun 4/260. Got perl 3.0 (beta), ran configure, make depend, make, then make test. On the latter it gives the message: sh: 24615 Memory fault - core dumped Did I answer something incorrectly in the configure script? (Most questions I used the default, not knowing any better). Could somebody send me their config.sh for the above hardware/OS? Many thanks, -- Ralph Finch ...ucbvax!ucdavis!caldwr!rfinch
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (09/08/89)
In article <550@caldwr.UUCP> rfinch@caldwr.UUCP (Ralph Finch) writes:
: I'm running SunOS 4.0.1 on a Sun 4/260. Got perl 3.0 (beta),
: ran configure, make depend, make, then make test. On the
: latter it gives the message:
:
: sh: 24615 Memory fault - core dumped
:
As a temporary workaround on Sun4, you need to
#define vfork fork
The problem is that on a Sun4, even registers are shared between parent and
child after a vfork, I am told. I've got a rewritten mypopen(), and several
other patches which I may send out soon, including one to keep shift and pop
from doing a double free when used on @_, and one which lets the idiom
chop($foo = <STDIN>);
work without trying to input an entire array, sigh.
Larry Wall
lwall@jpl-devvax.jpl.nasa.govguy@auspex.auspex.com (Guy Harris) (09/09/89)
>Did I answer something incorrectly in the configure script?
Probably not.
The problem appears to be due to the use of "vfork" in "mypopen" in
"util.c"; fixes to that and other problems (including previously-posted
"diff"s) are in another posting following this.
(As for why this is, we quote from the SunOS 4.0 <vfork.h>:
/*
* this atrocity is necessary on sparc because registers modified
* by the child get propagated back to the parent via the window
* save/restore mechanism.
*/
Now, if there weren't programs out there that relied, either explicitly
or implicitly, on the behavior of the BSD "vfork" implementation (e.g.,
C shell depending on the fact that it blocks the parent in order to let
it set up the process groups correctly - Chris Torek recently mentioned
what the right way to do that is in "comp.unix.wizards", I think - or
programs depending on the memory-sharing semantics that the manual page
went to great pains to tell you was NOT guaranteed to be there in the
future), "vfork" in 4.0 could just have been the same as "fork" as we
could have avoided all this pain. But nooooo....)