For what it's worth, the error message I got from gdb when I tried to 
debug one of the binaries that crashed while I was having my "memory 
corruption" was identical. Another R4000 user also got core dumps and 
couldn't compile stuff, just like the problems I was seeing.

I cvs'ed a new -current on the 8th which worked better, but not 
perfectly: gcc, ksh and login still give occasional core dumps.

If anyone needs more info on this, feel free to drop me a mail.

Cheers,
Gerald

Manuel Bouyer wrote:
> On Sun, May 09, 2004 at 12:02:13PM +0900, Christopher SEKIYA wrote:
> 
>>All,
>>
>>As previously discussed, libc.so.12.114 (as included in the 2.0 branch) causes
>>cache errors on sgimips (all supported platforms).
> 
> 
> I have a sgimips running 2.0 with libc.so.12.114 (Indy with R5000 CPU),
> and I didn't notice this king of troubles (the box is now running a
> build.sh release, it has already self-compiled the binaries it's running).
> However, I just noticed a strange behavoir of an older tcsh binary:
> islates:/home/sources/netbsd-2-0/src>alias ll
> ls -lgF
> islates:/home/sources/netbsd-2-0/src>ll /lib/libc.so*
> Segmentation fault (core dumped)
> islates:/home/sources/netbsd-2-0/src>ls -l /lib/libc.so*
> lrwxr-xr-x  1 root  wheel       14 May  6 20:13 /lib/libc.so -> libc.so.12.114
> lrwxr-xr-x  1 root  wheel       14 May  6 20:13 /lib/libc.so.12 -> libc.so.12.114
> -r--r--r--  1 root  wheel  1211356 Nov 20 16:05 /lib/libc.so.12.106
> -r--r--r--  1 root  wheel  1213904 Jan  4 04:10 /lib/libc.so.12.109
> -r--r--r--  1 root  wheel  1215822 Feb 13 23:24 /lib/libc.so.12.111
> -r--r--r--  1 root  wheel  1232648 May  6 16:25 /lib/libc.so.12.114
> islates:/home/sources/netbsd-2-0/src>gdb /usr/pkg/bin/tcsh tcsh.core 
> GNU gdb 5.3nb1
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "mipseb--netbsd"...(no debugging symbols found)...
> Core was generated by `tcsh'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/libexec/ld.elf_so...(no debugging symbols found)...
> done.
> Loaded symbols for /usr/libexec/ld.elf_so
> Reading symbols from /usr/lib/libtermcap.so.0...(no debugging symbols found)...
> done.
> Loaded symbols for /usr/lib/libtermcap.so.0
> Reading symbols from /usr/lib/libcrypt.so.0...(no debugging symbols found)...
> done.
> Loaded symbols for /usr/lib/libcrypt.so.0
> Reading symbols from /usr/lib/libc.so.12...(no debugging symbols found)...done.
> Loaded symbols for /usr/lib/libc.so.12
> 
> warning: Warning: GDB can't find the start of the function at 0x880692b0.
> 
>     GDB is unable to find the start of the function at 0x880692b0
> and thus can't determine the size of that function's stack frame.
> This means that GDB may be unable to access that stack frame, or
> the frames below it.
>     This problem is most likely caused by an invalid program counter or
> stack pointer.
> ---Type <return> to continue, or q <return> to quit---
>     However, if you think GDB should simply search farther back
> from 0x880692b0 for code which looks like the beginning of a
> function, you can increase the range of the search using the `set
> heuristic-fence-post' command.
> 
> warning: Warning: GDB can't find the start of the function at 0x880692b0.
> #0  0x880692b0 in ?? ()
>