Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!news
From: rpm@sgi1.wag.caltech.edu (Richard P. Muller)
Newsgroups: comp.sys.next
Subject: Re: Those ubiquitous core files and saving disk space
Message-ID: <1991Mar2.192816.27499@nntp-server.caltech.edu>
Date: 2 Mar 91 19:28:16 GMT
References: <23137@hydra.gatech.EDU> <442@heaven.woodside.ca.us>
Sender: news@nntp-server.caltech.edu
Reply-To: rpm@sgi1.wag.caltech.edu (Richard P. Muller)
Organization: California Institute of Technology, Pasadena, CA
Lines: 25
In-Reply-To: glenn@heaven.woodside.ca.us (Glenn Reid)

In article <442@heaven.woodside.ca.us>, glenn@heaven (Glenn Reid) writes:
>In article <23137@hydra.gatech.EDU> roy@prism.gatech.EDU (Roy Mongiovi) writes:
>> Actually, I've found it immensely helpful to create a /cores directory
>> so that all core dumps show up in one place.
>
>I've found it even more helpful to keep my applications from dumping core at  
>all when they crash.  If you type the following thing into a Terminal window,  
>it should keep core files from getting dumped anywhere:
>
>	localhost> limit core 0
>
[Stuff deleted]

I'm not familiar with the particulars of Mach, as I haven't yet gotten
my NeXT, but I'll answer with what I know.

Built into the csh (and maybe the Bourne shell?) is a command to limit
the size of a corefile. By typing 'set limit core N' you can limit the
corefile to N bytes.

The advantage to this is that it saves diskspace and time (sometimes
huge coredumps take forever...). The disadvantage is that very often
important information lies at the end of a corefile. Limiting the size
of the corefile will make it more difficult to analyze why the
computer failed in the first place.