Multithread Debugging

See Also

The following are tips for debugging multi-threading issues.

Breakpoint Filters

Some of the breakpoints support the application of thread filters. A thread filter causes the breakpoint to halt execution of the debuggee only when the breakpoint is hit from within the named thread. This can be useful for controlling when the breakpoint stops your program.

Breakpoint Expiration

An alternative to using a thread filter is to use a count filter. This simply means that you set the breakpoint to stop the debuggee up to a certain number of times. This can be used to allow the breakpoint to be hit once (or twice, or more) but thereafter it will be ignored.

To reset the breakpoint, simply change its expiration count.

Breakpoints Instead of println

Since each type of breakpoint displays a message in the Output window whenever the breakpoint is hit, it acts similarly to a call to println. The breakpoint hit message will always include the thread name or unique identifier, so you can easily see which threads are reaching a particular location. Just set the breakpoint suspend policy to "none" so that the impact on the thread timing in the debuggee will be minimal. This can be especially useful if you are debugging code that you cannot modify.

Note that some breakpoint monitors cause the debuggee to suspend momentarily, such as the expression and stack trace monitors. This will possibly affect the thread timing in the debuggee, so avoid using these monitors if the breakpoint suspend policy is "none".

Watching Field Changes

To catch a thread that is changing a field of a particular object instance, you can use a special type of variable breakpoint that is set on a per-instance basis. This is done via the Variables view context menu. This breakpoint will stop whenever the field of a specific instance of a class is modified, which can be very useful if the field is changing unexpectedly.

See Also


Legal Notices