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)
>