You often see in the breakpoints window that certain breakpoints are expandable:
These are called child breakpoints, and are a strong contender to the title of most poorly documented feature of VS. According to MSDN, child breakpoints occur –
…when you set a breakpoint in a location such as an overloaded function…
…when you attach to more than one instance of the same program.
And I’m not sure what they mean by either. AFAIK, a single debugger cannot attach to more than one instance of a program, and different overloads of the same functions reside in different code lines – so they cannot possibly count for child breakpoints.
It’s reasonable to assume that child breakpoints are generated whenever a breakpoint is set in a line of code that is compiled into multiple binary locations. I’m aware of two such scenarios – but there may be more:
- Templated function/method instantiated with different arguments,
- A function in a static library linked into multiple executables (exe, dll) in a single solution.
Perhaps by ‘overloaded function’ MSDN means (1) and by ‘more than one instance of the same program’ they mean (2)? I sure hope not. Also, the ever generous John Robbins confirmed the 1st case by email.
It’s good to be aware of this feature because it does have debugging performance implications – In a large project such that I work on, setting a breakpoint in (e.g.) smart pointer code results in spreading INT 3 instructions in thousands of instantiations – occasionally causing full minutes of IDE stall. There are often better alternatives – maybe more on that in a future post.
To make things even more interesting, in VS2005 this feature was badly bugged: more often than not a breakpoint was split into children for no apparent reason. This seems to be fixed in VS2010.