> My Sun 3/60 had been up for a couple of days when I started work on
> it this morning.  After about twenty minutes of pootling around, any
> programs less trivial than `ls' started giving me bus errors and
> dumping core (including gdb :-().

This sounds a lot like what I see.  I've been doing a lot of full
builds of the world on my -3/110, and it's rare for one to complete
(a full build takes like three days) without it dying at least once.
When it dies, the symptom is that any dynamically linked program (in
fact just about anything except reboot and halt) dies instantly on
startup, typically with SIGILL, or SIGBUS.  Nothing but a reboot cures
it as far as I can tell.

Personally, I suspect something wrong with the VM code; it's known that
mmap() does not interact well with the buffer cache (see the numerous
PRs about tail and vi breaking), and shared libraries are mmap()ped.

Note that it often dies before it installs _anything_; it is not
related to installing new versions of the .so files!

I also have a quite bizarre problem with my shell, which is kinda
legacy code...but I have no idea what's at fault, so even though it's
repeatable and apparently unrelated to the everything-coredumping
problem I haven't generated a PR for it.  (The problem?  When I log in
on the console and start my terminal emulator, if I'm in my home
directory the shell fails to start, saying
	`/local/mouse/bin/mcsh -fc 'echo $mcsh'`: No match.
	[1] 387
	# 
but if I'm in a certain subdirectory it works fine.  Starting a new
terminal emulator from the running one works regardless of directory.
I suspect something bizarre related to job control in the shell; the
code is much-ported code that started out as the 4.3BSD csh, and it may
well be subtly broken on systems that have walked down the POSIX
sessions path of good intentions.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu