5

I want accurate information about stack overflowing in VC++ (32 bit and 64 bit), and specially in recursion. In Debug mode, this happens so soon in recursion (like 4500 running of a simple recursive function don't do anything or like). However, it seems release mode is different. It was hard to understand, and I didn't test it by now, because optimization deletes the code that doesn't do anything (apparently removes recursion), as my code or function was so .. I should do more.. I measure the right time in optimized release, I don't know if optimization does the same in more complex quick sort implemented by recursion?

Thanks!

user683595
  • 377
  • 1
  • 3
  • 10

4 Answers4

7

As Andreas Brinck states in his related answer:

In VC++ the default stack size is 1 MB i think, so with a recursion depth of 10.000 each stack frame can be at most ~100 bytes.

This stack size limit can be modified using:

Project → Properties → Configuration Properties → Linker → System → Stack Reserve Size.

Project → Properties → Configuration Properties → Linker → System → Stack Reserve Size.

Community
  • 1
  • 1
Rahul Tripathi
  • 161,154
  • 30
  • 262
  • 319
1

The option for stack size in VC++ is located at,

Properties -> Configuration Properties -> Linker -> System -> Stack Reserve Size.
Sunil Bojanapally
  • 11,964
  • 4
  • 34
  • 43
0

You can do every recursive algorithm iterative e.g. with a seperate stack.

rekire
  • 46,262
  • 29
  • 163
  • 256
0

Whilst increasing the stack isn't a terrible idea, stackspace isn't infinite, and as you have probably noticed, running out of stack is not easily recoverable. If you MUST use recursive functions that recurse several thousand levels, then by all means increase the stack.

For safety, make sure that you do test the maximum safe recursion level, and then have a limit in your function [even in production code, even if it makes it a tiny bit slower and possibly take up more stack space]. Otherwise, you can bet that someone, somewhere, will use your code in a way you didn't anticipate, and have a crash when it runs a few levels deeper into the recursion than you anticipated - kablam, no possible recovery.

Another possible solution is to run your recursion in a separate thread, and if that thread crashes, you still have your main thread to recover from the crash in some sane way (if nothing else, simply to record the fact that your code crashed with a stack fail, and what the circumstances of that was).

I would certainly prefer to have a non-recursive, or at least limited recursion level, and use other mechanisms, such as dynamically allocated lifo data structure to record "where are we at".

Mats Petersson
  • 123,518
  • 13
  • 127
  • 216