Date: Wed, 10 Jan 1996 18:36:22 -0800 From: John Polstra <jdp@polstra.com> To: uh@NU.cs.fsu.edu Cc: j@uriah.heep.sax.de, freebsd-current@freebsd.org, nate@freebsd.org Subject: Re: make world Message-ID: <199601110236.SAA01847@austin.polstra.com>
next in thread | raw e-mail | index | archive | help
J"org wrote:
> As Gang-Ryung Uh wrote:
> >
> > I am trying to build the FreeBSD-current (which I downloaded 7 days ago).
> > But in the early stage of "make world", I got an following fatal error:
>
> > ===> rtld
> > install -c -s -o bin -g bin -m 555 -fschg ld.so /usr/libexec
> > install -c -o bin -g bin -m 444 rtld.1.gz /usr/share/man/man1
> > Memory fault
> > *** Error code 139
>
> > I am just curious in what situation the "Memory fault" message
> > can be generated. Would you tell me how to fix that problem?
>
> This seems to be the same problem i'm experiencing when trying to
> ``make release'', except i'm only getting it in the chroot'ed tree,
> with the make binary running from there. At least for me, it's `make'
> that segfaults here. And it does _not_ appear to be kernel- related!
> Has anybody been changing something in the area of malloc()?
To me, this looks very much like something that might happen if you had
just trashed your dynamic linker. Hey! What do you know?! He had _just_
installed a new dynamic linker. What a coincidence!
I don't like the way ld.so gets installed in the current Makefile.
There are many hazards lurking there.
I took a quick look at the sources of "install". It looks like, with the
options above, that install does this:
* unlinks the old version of /usr/libexec/ld.so
* copies the new version into /usr/libexec/ld.so
* runs /usr/bin/strip (itself dynamically-linked) on /usr/libexec/ld.so
Now, looking at the sources to "strip", it seems that it opens its file
read/write, and modifies it in place.
I've installed new versions of "ld.so" many times, and I can tell you
that modifying it in place like that causes very strange things to
happen. Such as, random core dumps from programs that normally work fine.
Then, as you run them repeatedly, the core dumps gradually become less
frequent. There's something strange going on, probably related to the
VM system.
Here's the safest way I've found to install a new version of ld.so on a
running system (taken from a shell script that I use):
test -f /usr/libexec/ld.so- && chflags noschg /usr/libexec/ld.so-
chflags noschg /usr/libexec/ld.so
install -c -s -o bin -g bin -m 555 ld.so /usr/libexec/ld.so+ &&
ln -f /usr/libexec/ld.so /usr/libexec/ld.so- &&
mv /usr/libexec/ld.so+ /usr/libexec/ld.so &&
chflags schg /usr/libexec/ld.so
This make sure that the system is never, even for a moment, without an
installed ld.so. It also takes care not to write over the old version,
which is still mmapped and possibly in use by running processes.
I'm going to modify the Makefile for ld.so to do something like this,
right away.
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601110236.SAA01847>