CODEWITHSUNDEEP
c++visual-studio-2010debugging
Nicolas Lefebvre
Nicolas Lefebvre

Reputation: 4282

Breaking During Function Evaluation in the Debugger

I'm trying to get this to work :http://msdn.microsoft.com/en-us/library/ms171381%28v=vs.100%29.aspx

More specifically, as mentioned on this other page, when using the immediate window to call a method, "If the function or subroutine contains a breakpoint, Visual Studio will break execution at the appropriate point."

Except... it doesn't, at least for me. You can try it with this dummy c++ test case :

#include "Windows.h"

void dbgbreak()
{
    DebugBreak(); // set a second breakpoint here
}

int main ()
{
    int i = 0;
    i++; // set a first breakpoint here
    return i;
}

Set the breakpoints mentioned in the source and run. When the debugger stops at i++, call dbgbreak() from the immediate window.

For me, the debugger does not stop again, even with two reasons to do so (an explicit second breakpoint inside the method called, plus the fact that the win32 API DebugBreak() should trigger a breakpoint).

Is this expected behavior ? That seems to be the exact opposite of what the documentation says... am I misunderstanding something ?

Upvotes: 3

Views: 744

Answers (1)

Hans Passant
Hans Passant

Reputation: 942020

Well, that actually works, just not the way you hope it works. Change the function to this:

void dbgbreak()
{
    OutputDebugString(L"Before\n");
    DebugBreak();
    OutputDebugString(L"After\n");
}

And when I use the Immediate window, I see this:

dbgbreak()
Before
The evaluation was aborted because an unhandled exception occurred.

Which is pretty accurate, DebugBreak() generates an exception. Which the debugger normally intercepts to put the program into a break state. Problem is, it is already in a break state. The feature that is missing is that the debugger doesn't support nested break states. For which it can be forgiven, that ought to be hard to implement since the Windows debugging api doesn't support it.

Beware that the MSDN page you linked talks about managed code. Which uses a very different kind of debugger. It is greatly aided by the CLR starting a dedicated thread that the debugger uses to evaluate watch expressions and immediate commands. And supports Debugger.Break() statements. Nothing similar exists in native code, managed code is a tool-builder's delight.

Upvotes: 3

Related Questions