Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!snorkelwacker.mit.edu!bloom-beacon!deccrl!news.crl.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!jit345!diamond
From: diamond@jit345.swstokyo.dec.com (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: Wierd core dump on sparc-1
Message-ID: <1991Jan25.033814.11554@tkou02.enet.dec.com>
Date: 25 Jan 91 03:38:14 GMT
References: <1991Jan23.232300.3698@lavaca.uh.edu> <1991Jan24.061653.22785@tkou02.enet.dec.com> <1991Jan24.214110.1478@cec1.wustl.edu> <1991Jan24.234658.27689@lavaca.uh.edu>
Sender: news@tkou02.enet.dec.com (USENET News System)
Reply-To: diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 44

In article <1991Jan24.234658.27689@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes:
>In article <1991Jan24.214110.1478@cec1.wustl.edu> abed@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@tkou02.enet.dec.com> diamond@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@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.