Is it possible to estimate the size a call function will need in the stack?

Question

Hi,

I am trying to understand a C code from another programmer. Sometimes I get segmentation faults and I think it could be due to stack overflow. I wonder whether in Visual Studio (or another way) is it possible to estimate in an easy way, given a call to a function, the size it will need on the stack when creating variables.

Thanks

Answer 1

You can get an estimate of the stack size used by a function by adding together the sizes of the local variables and the sizes used in _alloca() calls.
This is only an estimate, and will typically be a bit larger than the actual stack usage, but it should be enough to get a feeling if you are dealing with a stack overflow.

On the other hand, depending on the compiler settings, the stack will be several kilobytes is size and may even grow as needed.
If, at the point of crash, there really are only a few, small to moderate sized, frames on the callstack, it is far more likely that there is a problem with a pointer access or array index. Be sure to check also that your program does not have a wild pointer overwriting random memory.

Answer 2

The size of a frame on the stack is roughly the sum of the sizes of the parameters passed in plus the sum of the sizes of the local variables. There is also a little extra for the return address, base pointer, and perhaps some guard cookies for checking stack overruns.

Example:

int foo(int x, int y, char *string) {
  int array[10000];
  // ...
}

Integers in VC++ are 4 bytes each. A pointer is 4 bytes in a 32-bit executable, or 8 bytes in a 64-bit executable. So the parameters add up to 4+4+8. The local array is 40,000 bytes. This function consumes roughly 40 KB of stack. You could add up a lot of those before you overrun the stack.

An actual stack overflow in a Windows program generally only happens with runaway recursion. The default stack size is pretty large (1 MB). You can get stack corruption by overrunning a buffer that's on the stack.

Chances are your crash has to do with accessing an array beyond its bounds or accessing through a pointer that isn't pointing to valid memory (e.g., a NULL pointer).

Answer 3

I think a better approach here is to determine if a stack overflow exception is actually causing the issue. There is a setting in Visual Studio that will cause it to break if a stack overflow occurs. Set this, run the program under the debugger and you will know if a stack overflow is the problem.

• Debug -> Exceptions
• Expand Win32 Exceptions
• Check "Stack Overflow" thrown