debug stack overflow in windows?

Question

So I'm trying to debug this strange problem where a process ends without calling some destructors...

In the VS (2005) debugger, I hit 'Break all' and look around in the call stacks of the threads of the misteriously disappearing process, when I see this:

smells like SO http://img6.imageshack.us/img6/7628/95434880.jpg

This definitely looks like a SO in the making, which would explain why the process runs to its happy place without packing its suitcase first.

The problem is, the VS debugger's call stack only shows what you can see in the image.

So my question is: how can I find where the infinite recursion call starts?

I read somewhere that in Linux you can attach a callback to the SIGSEGV handler and get more info on what's going on.

Is there anything similar on Windows?

Answer 1

To control what Windows does in case of an access violation (SIGSEGV-equivalent), call SetErrorMode (pass it parameter 0 to force a popup in case of errors, allowing you to attach to it with a debugger.)

However, based on the stack trace you have already obtained, attaching with a debugger on fault may yield no additional information. Either your stack has been corrupted, or the depth of recursion has exceeded the maximum number of frames displayable by VS. In the latter case, you may want to decrease the default stack size of the process (use the /F switch or equivalent option in the Project properties) in order to make the problem manifest itself sooner, and make sure that VS will display all frames. You may, alternatively, want to stick a breakpoint in std::basic_filebuf<>::flush() and walk through it until the destruction phase (or disable it until just prior to the destruction phase.)