max size of automatic arrays?
Robert D. Silverman
bs at faron.UUCP
Mon Dec 9 02:16:27 AEST 1985
> I recently (and maybe a bit stupidly) tried to use a huge automatic array
> in an otherwise small C routine:
>
> /* foo.c */
> main()
> {
> double humongous[200000];
> write(2,"A OK\n",5);
> ....
> }
>
> which compiled OK but on an attempt to invoke got me an immediate:
>
> memory fault -- core dumped
>
> I then tried:
>
> /* foo.c */
> double humongous[200000];
> main()
> {
> write(2,"A OK\n",5);
> ...
> }
>
> which worked nicely.
>
> When I upped the 200000 to 400000 in this last, and tried again to invoke,
> I got:
>
> foo: too big
>
> which was at least more edifying than the 'core dumped' from the automatic
> array attempt. (There indeed was not enough space left in memory for both it
> and the kernel.)
>
> Question: Is this behavior (will invoke, not "too big," but core dumps)
> peculiar to a certain class of Unix systems, or will it happen on any Unix
> system? Sorry if I don't state this clearly enough. This happened on a
> Sys5r2 3B2/400 system. I don't have easy access to many other Unix systems to
> try this. Could this be because automatic variables go on the stack?
> (Shouldn't such a failure recover gracefully, rather than with a "memory
> fault"?) Trying to use "static" also worked, by the way, but produced a 1.6
> Meg executable and was a bit slow to compile and invoke.
>
> As always, thank you in advance, commenteers.
> --
> ------------------------------- Disclaimer: The views contained herein are
> | dan levy | yvel nad | my own and are not at all those of my em-
> | an engihacker @ | ployer or the administrator of any computer
> | at&t computer systems division | upon which I may hack.
> | skokie, illinois |
> -------------------------------- Path: ..!ihnp4!ttrdc!levy
The problem is a limitation in subroutine STACK size. Try saying 'unlimit
stacksize' before running your program. Making the array global took it
off the stack. The Unix 'limit' and 'unlimit' commands may be priviledged
on your system.
Bob Silverman
p
More information about the Comp.lang.c
mailing list