Why does Visual C++ not hit a breakpoint in, or step through a specific function?

Question

I have the following:

classA::FuncA()
{
 ... code
   FuncB();
 ... code
}

classA::FuncB(const char *pText)
{
    SelectObject(m_hDC, GetStockObject (  SYSTEM_FONT)); 
    wglUseFontBitmaps(m_hDC, 0, 255, 1000); 
    glListBase(1000); 
    glCallLists(static_cast<GLsizei>(strlen(pText)), GL_UNSIGNED_BYTE, pText); 
}

I can hit breakpoints anywhere in FuncA. If I try to step into FuncB, it steps over. It will accept a breakpoint in FuncB, but never hits it. I know it is executing FuncB, because I can put a MessagBox() call in FuncB and get the message box.

I'm new to VS2005 after a few years away from extensive VC6 usage. The one situation like this I recall from my VC6 days, is if symbol information is not available. However, in this case both functions are in the same file, so the symbol information must be correct. Also in that case I think you couldn't even set the breakpoint.

I've tried all the silly voodoo like rebuilding the whole solution.

What stupid thing am I overlooking?

EDIT: Added code for FuncB in response to comment about it possibly being essentially inline-able. (It's just the exact sample code from MSDN for wglUseFontBitmaps [minus comments here]). I don't see how inlining that would impede stepping through each call.

Answer 1

If everything fails try updating to VS2005 SP1 if you don't already have it...

Sounds strange indeed!

Answer 2

Make sure all compiler optimizations are disabled (/Od). Compiler optimization can cause problems with debugger breakpoints.

Answer 3

Not sure what the problem is, but one thing you might try is to look at the disassembled code. You can switch betwen the source code and disassbled view with VS. I do not have the IDE in front of me at work, so the terms might be slightly off.

If you put the debugger into this mode, you can see what the assembly instructions that are executing. This helps sometimes to determine these kinds of problems. Sometimes, although not usually with a debug build, calls are optimized out by the compiler.

Answer 4

Thanks for posting the code. This is clearly not what I had guessed.

---

For posterity's sake, and to clear things up, my guess was that if (1) the function was one line and (2) the compiler inlined the function, then (3) the debugger might not know how to step into it. This guess relies on the fact that some debuggers do have trouble with inlined code and other compiler optimizations. I'm not familiar enough with Visual Studio's debugger to say whether it is on that list.

On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. ...

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.

The GCC manual used to have a statement that some compilers would refuse to emit debugging symbols in optimized code because their debuggers couldn't follow it.

Answer 5

actually i had a similar problem, found out the code wasnt getting compiled when i was running the program, so make sure you 'compile' the program before you try running it