bs@faron.UUCP (Robert D. Silverman) (12/08/85)
> 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
brooks@lll-crg.ARpA (Eugene D. Brooks III) (12/09/85)
>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 have run into this problem before on Unix systems. The problem is that the data is on the stack. When the stack is expanded slowly, ie through routine calls with small ammounts of auto data memory faults occur. The kernel notices that the fault is close to current stack limit and expands the stack figuring that the user wants to expand the stack. If the user however expands the stack by several meg in one shot, as with a large auto array, the kernel has no way of knowing that the fault is just a stray pointer and assumes that it is. The limit for this change in strategy is probably set in the kernel somewhere and you could probably change it if you want.
peno@enea.UUCP (Pekka Nousiainen) (12/10/85)
>>main() >>{ >> double humongous[200000]; >> >>memory fault -- core dumped >data is on the stack. When the stack is expanded slowly, ie through routine >calls with small amounts of auto data memory faults occur. The kernel notices >that the fault is close to current stack limit and expands the stack figuring On Genix (tm?) and probably other systems too, the kernel checks if the instruction causing the fault is ENTER (enter a function). If it is, any memory reference is allowed. The core dump is caused by a software or a physical limit, sort of like using malloc(200000) and not checking the return value. But in this example no check is possible (except SIGSEGV). -- ...!mcvax!enea!peno.
levy@ttrdc.UUCP (Daniel R. Levy) (12/14/85)
Just a quick thanks to all those on the net who posted and mailed answers to my question. It is now apparent that in a sense automatic variables are "illegal" stack references which the system stretches the stack to honor up to some limit. I now note that the straw that broke the camel's back, so to speak, was the write() call made in the program (that is, if I did not use any of the locations in humongous[] and didn't call any functions [how boring] I was safe). -- ------------------------------- 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