Subject: Re: multisegment memory problems
To: Todd Vierling <tv@pobox.com>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm32
Date: 07/13/1998 17:42:44
Are you sure you aren't hitting a ulimit limit for a process?

I had problems like this when linking large binaries until I built a 
kernel with a higher set of limits.  IMHO the standard limits are 
ridiculously low.

Richard.

> I have cc1 coredumps that randomly happen on files that make cc1 grow >16MB;
> I have sendmail randomly thinking users are unknown when the system is at
> high load; and I have pine processes coredumping when their indices and
> buffers go beyond 16MB.
> 
> I'm convinced that there's something very wrong with MNN, or some other
> aspect of the VM system, and I dare anyone with a Shark to reproduce an easy
> testcase to prove that it's happening.  This isn't arm32-specific, but the
> sharks I have (both of them!  Bad memory, bah.) are the easiest way I've
> found to consistently reproduce the problem.  There's a recent PR for
> port-amiga that references this. 
> 
> Testcase (remember, this is for sharks with the standard 32MB):  Download
> and configure binutils 2.9.1 for a target of sparc-netbsd (or
> sparc-anything).  Turn off process limits (unlimit under csh).  Once
> configured, go into the opcodes directory and "make sparc-opc.o".  cc1
> should go a little fritzy and show you segments of some other file on your
> system that may currently be accessed or sitting in some random unused VM
> page.  Running the same test multiple times should show you the same
> weirdness. 
> 
> I can reproduce this on both Sharks, and the random behavior of Sendmail is
> a little shocking to go with this.  Any ideas?
> 
> -- 
> -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)
>