Joe Pruett wrote: >> I am modifying some C code. One function had a very large automatic >> variable. It was the array: >> jsProfile offLineProfiles[NUM_JOE_SCAN][NUM_BUF_PROFILES]; >> >> This array as an automatic variable worked in the older Slackware 9.1 >> 2.4.22 uni-processor systems. However, when I moved the code to a newer >> 2.6.27.7-smp, it would Segmentation fault in the function. Interesting >> thing was that it would fault when attempting a sprintf(). Using ddd, I >> could step through code in the function until the sprintf() was reached. >> >> In my various attempts to gain some insight, I added a printf() above >> the sprintf() - it faulted on the printf(). Finally, I moved the large >> array automatic variable and made it global - everything ran. >> >> So I looked at the array and calculated it's size to be 11,824,000 bytes. >> sizeof jsProfile == 2956 >> NUM_JOE_SCAN == 2 >> NUM_BUF_PROFILES == 2000 >> Looking at the older system from which I received the code, ulimit -s >> showed the stack size to be unlimited. >> The stack size on the newer system however is 8192. >> >> I am assuming that gcc-4.2.4 CFLAGS = -g -Wall -W >> places automatic variables on the stack. Is this a reasonable assumption? >> If so, creating the variable overran the stack and stomped all over >> something, maybe that function's index to C libraries - or???? >> >> Another interesting observation is that if I place the large array back >> in the function but return from the function before executing any C >> library calls, later C library calls to printf() etc. work fine. >> >> Any wisdom and insight here would be appreciated. >> > > i am assuming mean the new stack is 8192k (9 meg). you are correct to > identify that as the problem. calling a function requires using the stack > to record parameters for the called function, so by trying to allocate > more local storage than the stack would allow caused the cpu to try and > access memory outside the valid range and seg fault. any function could > have caused it, as well as any access to the beginning of the > offlineprofiles variable. if the function is not re-entrant, then making > it a global would work. so would making it be a static and malloc'ing it > on the first call. > Or malloc it and then free it when you're done. Just make sure that _every_ path out of the function goes through free (oh, I do like C++...).
-- Tim Wescott Wescott Design Services Voice: 503-631-7815 Cell: 503-349-8432 http://www.wescottdesign.com _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
