get VC debugger to show more frames in a stack overflow

Question

I was remote debugging a stack overflow from a recursive function. The Visual Studio IDE only showed the first 1,000 frames (all the same function), but I needed to go up further too see what the cause was.

Does anybody know how to get VS to 'move up' in a stack listing?

Thanks.

Answer 1

I do not believe there is a way to do this via the UI (or even a registry hack). My guess at the reason is showing all of the frames in a stack overflow situation can have a very negative performance impact.

Most stack frames are the result of bad recursion. If this is the case, you can likely set a conditional breakpoint on the target function. Set it to break only when the hit count reaches a certain level. I'd start with a count of around 1,000. You may have to experiment a bit to get the right count but it shouldn't take more than a few tries.

Answer 2

You could add a temporary recursion count parameter to the function, and assert when it goes over a maximum value. Give it a default value and you won't need to edit any other source

void f(int rcount /* = 0 */ )
{
 Assert(rcount < 1000);
 f(count+1);
}

Answer 3

I would suggest replace your debugging method and use logging to handle such problem. You might find it more productive, you just need to carefully choose what and when to print.
Any way analyzing few thousands lines of text will be much faster than going up few thousands stack frames. IMHO.
And you can use David's suggesting to control the amount of data to print (i.e pass relevant information from one recursion cycle to another)

Answer 4

You might also try WinDbg. It's not as friendly, but it sometimes works where the VC debugger doesn't.

Answer 5

I run into this now and then, what I do is add the following line to the function that is being called recursively:

static int nest; if (++nest == 100) *(char*)0 = 0;

The number 100 is arbitrary, often just 10 will work. This limits the recursion, ending it with a seg fault. The debugger should then show you the frames that started the recursion.

Answer 6

You are trying to solve this the wrong way.

There should be enough stack frames to show you the recurring call pattern. You should already be provided with enough inferential data to figure out how an infinite cycle of calls can happen.

Another hack idea might be to drastically decrease your stack size or artificially increase the size of each frame...