views:

651

answers:

2

During a make, I'm seeing an error along the lines of:

cc1: warnings being treated as errors
somefile.c:200: error: the frame size of 1032 bytes is larger than 1024 bytes

The line number points to the closing brace of a c function that has a signature like this:

void trace(SomeEnum1 p1, SomeEnum2 p2, char* format, ...) {
    char strBuffer[1024];
    ...

The function prints some stuff into the buffer.

Anyone know what this type of error means in general?

+8  A: 

I'm guessing there's some large buffer in that routine that is stack-allocated; this is likely causing the stack frame of that function to exceed 1024 bytes, which seems to be some compiler-enforced limit for the architecture upon which you are building. Possible solutions would include passing a compiler flag to relax the warning, expand the upper limit of the stack size, or dynamically allocating the buffer.

fbrereto
In fact the first thing that happens is an allocation of a buffer of size 1024.
Pierre-Antoine LaFayette
Man I was gonna say this too, but I wanted to see the function first. :)
GMan
I've upvoted your comments for good intentions :)
Pierre-Antoine LaFayette
A: 

Here is the GCC documentation referring to this warning:

STACK_CHECK_MAX_FRAME_SIZE

The maximum size of a stack frame, in bytes. GNU CC will generate probe instructions in non-leaf functions to ensure at least this many bytes of stack are available. If a stack frame is larger than this size, stack checking will not be reliable and GNU CC will issue a warning. The default is chosen so that GNU CC only generates one instruction on most systems. You should normally not change the default value of this macro.

From http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC214

Pierre-Antoine LaFayette
The stack frame is where the compiler places auto variables. If you have any local variables other then strBuffer you're going to overflow the 1024 limit. Try to reduce the size of strBuffer to make room for additional local variables. The compiler may also use some space in the stack frame for it's own use, typically saving the return address and hardware registers.
Robert Menteer
You can also try moving strBuffer from the stack to some other memory area like the heap or global memory. Moving it to the heap would require using malloc and free and you'd take a performance hit. While moving it to global space would only require adding the 'static' qualifier, but you'd loose some global space. I'm making all kinds of assumptions about your hardware and compiler.
Robert Menteer