5

I have written a function in C, which, when called, immediately results in a stack overflow.

Prototype: void dumpOutput( Settings *, char **, FILE * );

Calling line: dumpOutput( stSettings, sInput, fpOut );

At the time of calling it, stSettings is already a pointer to Settings structure, sInput is a dynamically allocated 2D array and fpOut is a FILE *. It reaches all the way to the calling line without any errors, no memory leaks etc.

The actual function is rather lengthy and i think its not worth sharing it here as the overflow occurs just as the code enters the function (called the prologue part, i think)

I have tried calling the same function directly from main() with dummy variables for checking if there are any problems with passed arguments but it still throws the stack overflow condition.

The error arises from the chkstk.asm when the function is called. This asm file (according to the comments present in it) tries to probe the stack to check / allocate the memory for the called function. It just keeps jumping to Find next lower page and probe part till the stack overflow occurs.

The local variables in dumpOutput are not memory beasts either, just 6 integers and 2 pointers.

The memory used by code at the point of entering this function is 60,936K, which increases to 61,940K at the point when the stack overflow occurs. Most of this memory goes into the sInput. Is this the cause of error? I don't think so, because only its pointer is being passed. Secondly, i fail to understand why dumpOutput is trying to allocate 1004K of memory on stack?

I am totally at a loss here. Any help will be highly appreciated.

Thanks in advance.

6
  • you googled for stack overflow and found this site? Commented Feb 3, 2012 at 11:15
  • How does dumpOutput() know the size of the sInput array? Could your code me not terminating at the end of the data to dump? You could flush each byte as it is written to FILE to see how much data is written and if it matches your expectation. Commented Feb 3, 2012 at 11:17
  • As the arguments are all pointers, they should not take more that 3*8 (on 64-bit systems) bytes of memory on the stack. Can you add the first few lines of the function to the question? And maybe the complete declaration of the arguments, and the actual call and a couple of lines before that? Commented Feb 3, 2012 at 11:19
  • By the way, maybe the callstack when this error happens might be good to see as well. Commented Feb 3, 2012 at 11:21
  • @peterept thanks, it turned out to be an overlooked array.. Commented Feb 3, 2012 at 14:04

2 Answers 2

5

By design, it is _chkstk()'s job to generate a stack overflow exception. You can diagnose it by looking at the generated machine code. After you step into the function, right-click the edit window and click Go To Disassembly. You ought to see something similar to this:

003013B0  push        ebp  
003013B1  mov         ebp,esp 
003013B3  mov         eax,1000D4h                  ; <== here
003013B8  call        @ILT+70(__chkstk) (30104Bh) 

The value passed through the EAX register is the important one, that's the amount of stack space your function needs. Chkstk then verifies it is actually available by probing the pages of stack. If you see it repeatedly looping then the value for EAX in your code is high. Like mine, it is guaranteed to consume all bytes of the stack. And more. Which is what it protects against, you normally get an access violation exception. But there's no guarantee, your code may accidentally write to a mapped page that belongs to, say, the heap. Which would produce an incredibly difficult to diagnose bug. Chkstk() helps you find these bugs before you blow your brains out in frustration.

I simply did it with this little test function:

void test()
{
    char kaboom[1024*1024];
}

We can't see yours, but the exception says that you either have a large array as a local variable or you are passing a large value to _alloca(). Fix by allocating that array from the heap instead.

Sign up to request clarification or add additional context in comments.

1 Comment

thank you for the help. in my case, the eax happened to be 437014h, which surely is large. It turns out that i was overlooking another local array which accidentally had a very large size. fixing it fixed the problem! thanks again! you rock! :)
0

Most likely a stack corruption or recursion error but it's hard to answer without seeing any code

1 Comment

no recursion, but it was a stack corruption due to very large array. thank you for your help! :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.