Wierd core dump on sparc-1

[Norman Diamond]

In article <1991Jan24.234658.27689 at lavaca.uh.edu> jet at karazm.math.uh.edu ("J. Eric Townsend") writes:
>In article <1991Jan24.214110.1478 at cec1.wustl.edu> abed at saturn.wustl.edu (Abed M. Hammoud) writes:
>>>Good idea.  Why didn't you try it before posting?
>
>I did, several different ways.  I was going to try it some *more*...
>
>>In article <1991Jan24.061653.22785 at tkou02.enet.dec.com> diamond at jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>>	I had the same problem a couple of weeks ago. (also on a sparc
>>	1+ station). I was using a number of large arrays. by keeping
>>	the same array sizes and changing their type from double to 
>>	float the problem disappear. So for some reason it seems it has
>>	something to do with big arrays.

I am Norman Diamond.  I wrote "Good idea..." and am glad to hear that you
did try it before posting, but not so glad to see you mix up the attributions.

>Aha!  I'm using big arrays of doubles as well.    A quick
>:%s/double/float/g
>produced a source, that when compiled, did *not* dump core.

So, the second possibility that I mentioned, the stack limit or similar
restriction, seems to be correct.  If you have csh, try:
% limit stacksize unlimited
and/or
% limit datasize unlimited
I don't know what these commands would be under other shells.

These don't actually give you unlimited space; they only raise the soft
limits to match the hard limits that were set when your kernel was
compiled.  If these aren't enough, then see about recompiling your
kernel with higher hard limits.  (Also a superuser's shell should be
able to raise its hard limits for the duration of its session.)

>ld -o foo foo.o
>produces a file that *does* dump core.

Of course.  You need the C run-time start-up routine.

>Looks like a 4.0.3c compiler bug.

Not yet.
--
Norman Diamond       diamond at tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.