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. Wayne _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
