Question

I have a multi-threaded application that I’m debugging inside the IDE (Visual Studio 2008, Win7-64, C++).

For “debugging” purposes, I “pretend” that I always have a single processor (the program detects the number of local processors), but the program design establishes a minimum of two threads (e.g., the “main thread” which handles GUI and event traffic, and a second “processing” thread where work is moved off of the “main thread”). (In a “production” build there would be a single main thread, and one-or-more “processing” threads depending on the number of detected processors.)

ISSUE: Breakpoints in the code (within the IDE) sometimes are triggered, and sometimes not. Re-running the program may “catch” on a break point where the previous run it did not “catch” (no source code changes or rebuild is performed to see this change-in-breakpoint-catch-behavior, the program execution path is identical).

(I mostly only care about triggering breakpoints in the non-GUI/non-main-thread, but I assume that should not matter.)

QUESTION: Is there a way to make these break points catch more “reliably”? (What influences whether a break point “catches” or not?)

I’m aware of, and NOT concerned with the following:

• Source is out-of-sync with latest linked executable
• Build is not “debug” (no debug symbols available)
• “Clean build” is needed (debug artifacts out-of-date)
• “Step Over/Into” may not work properly when another thread “breaks”
  during that first thread’s stepping operation

On web searches, there was a mention of possibly setting the compiler setting to “x86” and not “Any Processor” to catch breakpoints, not sure why that might matter … ?

Finally, yes, of course, all logic “should” be tested in a single-threaded application (e.g., re-factor to ensure deterministic single-threaded execution for unit and regression tests). However, for the current testing, I need to be in the “real” application (think “integration testing” or “systems integration”).

Answer 1

Normally breaking is extremely reliable. Here are some things to try:

1. Hard code a breakpoint with DebugBreak(). This should always be caught, but if this exhibits the same broken behavior, you have narrowed down the problem.
2. Where you currently have the bp set, add a line to print to screen/file, and set the breakpoint on that line. This is to be certain this line is really even being hit. You may have a strange, unexpected bug that is actually skipping the entire section unexpectedly and this is necessary to be sure.
3. Try with and without any optimizations. Debugging works best with all optimizations off, but even with deadstripping and inlining features at work, breakpoints are expected to still work. Does this issue occur even with optimizations off?
4. You say ISO C++, does this mean you’ve actually switched off all microsoft extensions? I’ve never compiled this way in visual studio, but if you have, try switching extensions back on and see if that has any effect.