MultithreadedDebugging

New Multithreaded Debugging Support

This is a summary description for the new Multithreaded Debugging Support that will be available in NB 6.5. These bits have been done as a first phase of the overall NB debugger redesign effort, which goal is to significantly improve the debugging workflow and usability.


Debugging Window

[[{ImageSrc=MultithreadedDebugging/DebuggingWindow_MultithreadedDebugging.PNG} | {Image src='MultithreadedDebugging/DebuggingWindow_MultithreadedDebugging.PNG}]]
In order to improve UI for multithreaded debugging and also willing to reduce the number of debugger views, a new (unifying) debugger view is introduced. This view (referred as Debugging View) integrates current Sessions, Threads and Call Stack views being displayed in the Explorer group by default.

From the technical perspective, the Debug view is organized as (in general) a list of sessions, having each session as a list of threads, each suspended thread than expandable to its call stack and more. Debug view is customizable via context options only showing typically needed info by default. With the 'Suspend Table' switched on, any thread can be resumed/suspended by one click on the dedicated button.

If there is the debugger counter displayed in the editor and another thread encounters a breakpoint, the current thread will not be automatically switched. Instead, a non-modal panel is displayed in the bottom of Debugging view informing that there are new breakpoint hits waiting; there is also a drop-down button switching the debugger to the next (or selected) breakpoint hit. Having this non-modal notification, users are allowed to finish their debugging of current thread (e.g. expression evaluation) and switch to next breakpoint hit when it fits to the workflow.


Current Thread Chooser

[[{ImageSrc=MultithreadedDebugging/CTChooser_MultithreadedDebugging.PNG} | {Image src='MultithreadedDebugging/CTChooser_MultithreadedDebugging.PNG}]]
When doing a multithreaded debugging, it is often needed to quickly switch between particular threads; e.g. when doing a stepping sequence in two threads alternately. For such purpose we introduce a new action--Current Thread Chooser (CTRL+8). In fact, it is an analogy to application switching common in OS environment. With this feature, it is really straightforward to revisit any thread for debugging or switch to a particular thread for the first time.


'Other Thread(s) Suspended Here' Gutter Navigation

[[Image:MultithreadedDebugging/gutter_MultithreadedDebugging.png}]]
Anytime the debugger displays the thread icon in the editor gutter, the user is informed that there is/are one or more suspended non-current thread(s) at this line. The list of these threads can be seen in the icon tooltip, and it is also possible to switch debugging to any of these threads via the context menu. Strictly speeking, it is the Source->Threads navigation available in the editor gutter.


Deadlock Detection

[[{ImageSrc=MultithreadedDebugging/DeadlockDetection_MultithreadedDebugging.PNG} | {Image src='MultithreadedDebugging/DeadlockDetection_MultithreadedDebugging.PNG}]]
The debugger automatically searches for deadlock among all suspended threads. When a deadlock is detected, a non-modal notification is displayed having emphasized involved threads. Detailed monitor info is also available displayed in dedicated monitor nodes.


New Threading Model

In order to improve multithreaded debugging, we decided to change the way how debugger manages debuggee threads. The main issue related to current model (NB 6.1 and older) is likely the fact that any step resumes all threads regardless there are threads intentionally suspended by the user or not. This can be limiting e.g. in case of debugging race conditions or deadlock issues. The natural solution to this problem is to resume only the current thread leaving other threads suspended if they are (may have happened via breakpoints or Suspend action). Obviously, this change needs the default breakpoint to suspend only the breakpoint thread, otherwise stepping could lead to so-called Deadlock Caused by Debugger.

Current Model Summary (NB 6.1 and older):

  • Default breakpoint suspends all threads.
  • Step resumes all threads when invoked and suspends all threads when completed regardless there are threads intentionally suspended or not.
  • Evaluation is done only resuming the current thread (by default), which may easily lead to 'deadlock caused by debugger' in current model.
  • 'Step interrupted by a breakpoint' issue exists with default breakpoint.

New Model Summary:

  • Default breakpoint only suspends breakpoint thread.
  • Step only resumes current thread when invoked and suspends current thread when completed.
  • Evaluation is done resuming the current thread (other threads unsuspended by default breakpoint or step). No deadlock caused by debugger might happen as far as no thread is explicitly suspended by the user (via suspend action or some breakpoint).
  • 'Step interrupted by a breakpoint' issue does not exist with default breakpoint. (Except the stepping thread itself encounters a breakpoint.)
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo