Поделиться через

Debugger tip for stack overflows

  • Статья

Every so often my team likes to make me feel useful.  I don't get to write code and fix bugs as much as I used to when I arrived at Microsoft, but I do have a good few tricks up my sleeve.  Someone from the profiler team was looking at a stack overflow in the analysis code that occured from some recent changes.  As ever, these come from cyclic recursion patterns, and so you get the same few methods on the stack, and no good way to identify "when to stop" and what to inspect just before the exception:

A
B
C
A
B
C 
...

My trick here is simple, and it's to do with "hit count" breakpoints. Set a breakpoint in one of the methods, but go ahead and add a hit count.  You do this via:

Right click on the breakpoint->Select Hit Count...->hit when the hit count is greater than or equal to

Crank the hit count up to something insane (I tend to use 65536).  Now let the program run to the crash point and see that the breakpoint never fires.  Now go to the breakpoints window and look at the hit count for your breakpoint and it will tell you how many times that the code executed that breakpoint.  Now go ahead and change the breakpoint hit count to only hit at that count or one or two below, and now you can debug through the last throes of the stack overflow....

Happy slaying! (Sorry for the lack of pictures)...

John

Comments