Child Breakpoints in Visual Studio

You often see in the breakpoints window that certain breakpoints are expandable:

bpwin1

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:

  1. Templated function/method instantiated with different arguments,
  2. 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.

Advertisements
This entry was posted in Debugging, Visual Studio. Bookmark the permalink.

One Response to Child Breakpoints in Visual Studio

  1. Just a quick note, as I’ve just discovered your (very interesting) blog :
    You can attach the debugger to several applications !
    The attach menu entry is present, even when the debugger is already attached to a process.

    Actually, on some rare occasions, I even found it useful to debug some network code, attach the debugger to both the client and the server, and add some tracepoints to trace the network flow…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s