iand@mullian.ee.mu.OZ.AU (Ian Robert DOBSON) (09/05/90)
I just went out and bought THINK C 4.0 and have come across an interesting
bug. Using the "ANSI" and "MacTraps" libraries with default project settings
(384K, no 68020/68881 etc.) bombed the machine when executing the following
code:
#include <stdio.h>
main()
{
char array[32000];
printf("\nHello, world!\n");
}
The array allocation bombs the machine, the printf never executes, and after
a click or two the menus jam up and the machine needs a reboot.
Can anybody suggest any reason for this problem, and any remedy without
dynamically allocating the array with 'malloc', 'NewPtr' etc.
Ian R. Dobson
Dept. of Electrical Engineering
University of Melbourne, Australia
(internet: iand@mullian.ee.mu.oz.AU)hawley@adobe.COM (Steve Hawley) (09/06/90)
In article <5364@munnari.oz.au> iand@mullian.ee.mu.OZ.AU (Ian Robert DOBSON) writes: >I just went out and bought THINK C 4.0 and have come across an interesting >bug. Using the "ANSI" and "MacTraps" libraries with default project settings >(384K, no 68020/68881 etc.) bombed the machine when executing the following >code: > >#include <stdio.h> > >main() >{ > char array[32000]; > > printf("\nHello, world!\n"); >} Here's why it bombs: array is a local variable to the function main. array is allocated on the stack when main is entered. This allocation happens before the printf, and hoses the machine since 32000 bytes is really an awful lot to ask from the machine as local variable space for a single function, since the limit imposed by the compiler is 32K. If you REALLY feel you have to do this, try making your array static (which will limit you to only another 767 bytes of global and static data), which puts it in global space. Or (I know this isn't what you want to hear) allocate it on the fly from the heap. The heap will probably be much much larger than the stack. Remember the purpose of local variables: small amounts of storage for variables you will need temporarily that can be used re-entrantly (otherwise recursion won't work as well as you'd like it to). If you want to see death in a C environment, try the following program on a variety of machines: #include <stdio.h> int deathcount = 0; death() { char a[1024]; /* 1K allocated on the stack */ a[0] = a[0]; /* prevent a from being linked out by an optimizer */ printf("%dK"\n", ++deathcount); fflush(stdout); death(); } main() { death(); } On a Sun 3/80 with all the wonders of UNIX memory management, it can only cope with 2036K (!!) before it core dumps. Try it on a Mac to see what it's limits are (I can't, since I don't have a Mac anymore (sniff)) under Think C. Steve Hawley hawley@adobe.com -- "I can always telephone, but I can't tell it much." -Roy Blount
pepke@gw.scri.fsu.edu (Eric Pepke) (09/07/90)
In article <6280@adobe.UUCP> hawley@adobe.COM (Steve Hawley) writes: > This allocation happens before the printf, and > hoses the machine since 32000 bytes is really an awful lot to ask from the > machine as local variable space for a single function, since the limit imposed > by the compiler is 32K. More to the point, the default stack size of the Macintosh is only about 5K. If you compare the address of the array to the address of the function, you should find that the function code itself is somewhere within that array. There's no telling what you are dinking with, and you should not really be surprised when it bombs. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.