[PLUG] Interesting C problem

[Jason Dagit]

On Thu, Sep 3, 2009 at 2:44 PM, Wayne E. Van Loon Sr.<wevl at pacifier.com> 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.

There is a little known non-standard (but common) function in C called
alloca that works for this sort of thing:
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_3.html#SEC45

I have no idea how old that documentation is, but it seems to describe it.

Jason