[PLUG] Interesting C problem

Joe Pruett joey at clean.q7.com
Thu Sep 3 21:56:48 UTC 2009


> 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.



More information about the PLUG mailing list