torek@elf.ee.lbl.gov (Chris Torek) (02/14/91)
>>In article <1991Jan23.232300.3698@lavaca.uh.edu> jet@karazm.math.uh.edu >>("J. Eric Townsend") writes: >>>I've got a rather simple little C program that dumps core at >>>the first "{" of main() (according to gdb and saber). >>>Any hints as to what could be causing this? In article <1991Jan24.214110.1478@cec1.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes: >I had the same problem a couple of weeks ago. ... I was using a number >of large arrays. ... I will be interested to know what really causes >this problem. The answer is `large arrays'. Many computers place some sort of limit on the size of a `stack', and many C compilers use a stack to implement automatic (local) variables. The SparcStation compilers are examples of the latter. The SparcStation itself has fairly large limits (512 MB, minus the virtual size of the kernel [including DVMA space]); the kernel imposes more restrictive limits to stop runaway programs early. This is usually a good thing. When the kernel-imposed stack limit gets in your way, you can (under SunOS, and on other machines, under 4BSD) use the C-shell built-in `limit' command (or the unlimit command) to raise it: % limit stacksize stacksize 8192 kbytes % limit stacksize 16m % limit stacksize stacksize 16384 kbytes % unlimit stacksize % limit stacksize stacksize 393216 kbytes % On some machines, such as IBM PCs, the hardware stack size limit is much smaller (e.g., 65536 bytes) and the easiest fix is to change the way local data are allocated (use malloc and large model). On some machines, the addressing modes used by the compilers limits any individual object's size: some 68010 compilers (e.g., for the Mac) might not work with any object that is larger than 32767 bytes, nor any stack frame (read, `set of current automatic variables') that sums to more than 32767 bytes. Worse, some of these will generate incorrect code without even a warning. In general, large automatic objects (such as large arrays that are local to one function) will cause programs to behave oddly on some systems. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov