lamaster@pioneer.arpa (Hugh LaMaster) (11/30/87)
Is there a limit to the maximum size of an array using cc? For some reason, the maximum number that NR can be on a Sun (3.2) is 128766. On a VAX (Ultrix 2.0) it is 130222. Am I doing something wrong or is it the compiler? ****************************************** Script started on Mon Nov 30 16:36:33 1987 csh[1] more junk2.c #include <stdio.h> #define NR 128767 [m main() { int nr ; int red[NR]; [m nr = NR; [m for ( nr = 0; nr < NR; nr++ ) { red[nr] = nr ; [m } printf("\n red[%d] = %d\n", NR-1,red[NR-1] ); } csh[2] cc junk2.c csh[3] a.out Segmentation fault (core dumped) script done on Mon Nov 30 16:40:12 1987 Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility")
chris@mimsy.UUCP (Chris Torek) (12/01/87)
In article <3537@ames.arpa> lamaster@pioneer.arpa (Hugh LaMaster) asks: >Is there a limit to the maximum size of an array using cc? and notes that the following program (my condensed version) crashes: #define NR 128767 main() { int red[NR]; red[0] = 0; } Time for the semi-annual stack size discussion again, I see.... Assuming that your compiler implements local arrays by using a stack, there are several reasons for size limitations: 0) The compiler may use a register offset addressing mode with a fixed maximum offset. Old Sun 68000 compilers, for instance, used a6@(offset), which limits the maximum offset to -32768, or 8192 four-byte integers. 1) There may be a total stack size limit imposed by the operating system and/or machine architecure. `Large model' compilers for the 80x86 family tend to use a single stack segment, limiting one to 65536 bytes of stack. 2) [the one that bit you] The 4BSD kernels (upon which the Ultrix kernels are based), like many other paging systems, want to be able to tell a `good' stack reference fault, where a program is growing its stack in a properly controlled manner, from a `bad' fault, where the program has managed to put junk into its stack pointer, or something equally incorrect. To this end it has a `stacksize' resource limit. In 4.3BSD, the default value for this limit is 512 kB. The program above uses very nearly 512k for the array `red' alone; the space required for the rest of the program makes running that program exceed this. Solution: use the C-shell built in `limit' command, e.g., `limit stacksize 1m' (yes, megabytes should be M, but csh refuses to believe in millibytes :-) so you may use lowercase). The built-in `unlimit' command raises a limit to its maximum value. Alternatively, the program itself can set its stacksize limit. For details, see man 1 csh and man 2 setrlimit. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/01/87)
In article <9583@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > Solution: use the C-shell built in `limit' command, ... A better solution would be to change the code so as not to allocate so much on the auto stack. There are many machines with much smaller stack size limits, and code that assumes an "infinite" stack will not port to such machines. Huge amounts of space are best obtained via malloc().
carroll@snail.UUCP (12/01/87)
Sounds to me like it's not a problem in the compiler, but that there is a finite amount of space in your stack segment. And when you try to allocate 1/2 M of stack, the OS "just says no".
daveb@laidbak.UUCP (Dave Burton) (12/02/87)
In article <9583@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <3537@ames.arpa> lamaster@pioneer.arpa (Hugh LaMaster) asks: >>Is there a limit to the maximum size of an array using cc? >and notes that the following program (my condensed version) crashes: > #define NR 128767 > main() { int red[NR]; red[0] = 0; } > Solution: use the C-shell built in `limit' command, e.g., > `limit stacksize 1m' (yes, megabytes should be M, but csh > refuses to believe in millibytes :-) so you may use lowercase). > The built-in `unlimit' command raises a limit to its maximum > value. Alternatively, the program itself can set its stacksize > limit. For details, see man 1 csh and man 2 setrlimit. Or better yet, use some variant of MALLOC(3), maybe: #include <stdio.h> #define NR 128768 /* or other suitably large value */ main() { int *red; if ((red = (int*)malloc(NR)) == NULL) { fprintf(stderr, "cannot alloc %ld bytes\n", NR); exit(1); } red[0] = 0; /* etc. */ exit(0); } Changing the shell limit will allow that invocation to work, but future invocations will fail the same as the original. Fix your program, don't fix BSD. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include <disclaimer.h> Naperville, IL 60540
rushfort@esunix.UUCP (Kevin Rushforth) (01/21/88)
in article <3537@ames.arpa>, lamaster@pioneer.arpa (Hugh LaMaster) says: > Is there a limit to the maximum size of an array using cc? For > some reason, the maximum number that NR can be on a Sun (3.2) is > 128766. On a VAX (Ultrix 2.0) it is 130222. Am I doing something > wrong or is it the compiler? [relevant part of example follows] > #define NR 128767 > main() > { > int red[NR]; > } This is not a limit on the size of an array imposed by your compiler, but rather a limit on the stack size imposed by your OS. 4.2/4.3 based Unix systems (as well as others) have compiled in limits on stack size (the csh command "limit" will tell you how much). To avoid the problem, declare your array statically or malloc() space for it: main() { static int red[NR]; } -or- main() { int *red; red = (int *) malloc(NR * sizeof(int)); } -- Kevin C. Rushforth Evans & Sutherland Computer Corporation UUCP Address: {ihnp4,ucbvax,decvax,allegra}!decwrl!esunix!rushfort Alternate: {bellcore,cbosgd,ulysses}!utah-cs!esunix!rushfort
ok@quintus.UUCP (Richard A. O'Keefe) (01/24/88)
In article <594X@esunix.UUCP>, rushfort@esunix.UUCP (Kevin Rushforth) writes: > This is not a limit on the size of an array imposed by your compiler, > but rather a limit on the stack size imposed by your OS. 4.2/4.3 based > Unix systems (as well as others) have compiled in limits on stack size > (the csh command "limit" will tell you how much). The limit is not compiled-in. (There may be a compiled-in limit, but the number Csh will tell you is usually well below it.) For example, % limit stacksize on my machine just now reported stacksize 512 kbytes I then said % limit stacksize 2M and it raised the limit to 2 megabytes. This isn't really a good idea. 4BSD systems also have a rather nice function alloca(size) allocates that much space in the stack; it will go away when the calling function returns. The stack size limit applies to alloca() as well as to explicitly declared arrays.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/25/88)
In article <570@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <594X@esunix.UUCP>, rushfort@esunix.UUCP (Kevin Rushforth) writes: >The [stack] limit is not compiled-in. On some implementations (even of 4.nBSD), it is. For example, Gould UTX-32. >4BSD systems also have a rather nice function > alloca(size) >allocates that much space in the stack; it will go away when the >calling function returns. alloca() predates BSD. Its use was stamped out in real UNIX, because not all implementations could support a reasonable alloca(). Inspired by discussions with J Q Johnson and others, I came up with a "mostly portable" implementation of alloca() that I posted a couple of years ago. It doesn't work on some IBMs and other inhospitable implementations, though. Contact me if you need a copy. - Gwyn@BRL.MIL