Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/DD/MultiContext"

< DSDP‎ | DD
m
m
Line 1: Line 1:
This sub-group is focused on improving the workflow of multi-context debugging.  ''Multi-context'' refers to simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views.   
+
This sub-group is focused on improving the workflow of multi-context debugging.  ''Multi-context'' refers to simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views.  This sub-group was created following a discussion about platform debug dev: [http://dev.eclipse.org/mhonarc/lists/platform-debug-dev/msg01179.html "ideas for improving multi-context debugging"].   
  
This sub-group was created following a discussion about platform debug dev: [http://dev.eclipse.org/mhonarc/lists/platform-debug-dev/msg01179.html "ideas for improving multi-context debugging"]. 
+
Old previous documents produced by this group
 
+
Other old documents:
+
 
* [[DSDP/DD/MultiContext_UnlinkViewContextProposal|Unlink View Context proposal]]
 
* [[DSDP/DD/MultiContext_UnlinkViewContextProposal|Unlink View Context proposal]]
  

Revision as of 01:44, 3 April 2008

This sub-group is focused on improving the workflow of multi-context debugging. Multi-context refers to simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views. This sub-group was created following a discussion about platform debug dev: "ideas for improving multi-context debugging".

Old previous documents produced by this group

Use cases

Use cases to be considered when evaluating the multi-context debugging workflow.

Format:

  • Family of use cases
    Use case 
    Description of the use case
    Scenario
    • Step


  • I. Programs with multiple threads
  • 1 Two or more threads interacting 
    User is debugging a program with multiple threads which are interacting with each other.
    a) Debugging threads which contend for the same lock. 
    1. When a thread blocks while stepping,
    2. User switches focus to another thread and steps until the lock is released,
    3. User switches focus back to the first thread and continues debugging.
    b) Debugging race conditions where multiple threads are reading and writing some shared data 
    1. User sets a breakpoint at a location where a shared variable is written.
    2. Multiple threads hit the breakpoint
    3. User looks at each threads to see the thread-private data in each thread.
    4. User steps the threads individually to watch what happens to the shared data.
    5. Alternatively, user steps all threads.
    6. Multiple threads may hit the breakpoint at the same time.
    7. User sets another breakpoint further down in routines that access the shared data.
    8. User continues some or all of the threads which stopped at the first breakpoint so that they may reach the second breakpoint.
  • 2 Debugging a subset of threads 
    User is debugging a program with multiple threads, but he is interested only in interacting with some of the threads.
    a) User debugs with breakpoints restricted to a sub-set of threads.
    1. User creates a breakpoint on the routine to be debugged.
    2. User defines which threads should be allowed to hit the breakpoint.
    3. The threads hit the breakpoint and user steps through them.
    b) Run control for a subset of threads 
    User repeatedly suspends and resumes a subset of threads.
    c) Terminating/re-launching 
    1. User debugs a subset of threads (using filtered breakpoints, etc.).
    2. User terminates and relaunches a process, and continues to debug the same set of threads.
  • 3 Program with large number (100+) of threads 
    User is debugging programs with large numbers of threads and he needs to manage those threads effectively.
    a) User needs to switch between suspended threads
    1. User sets a breakpoint that some threads may hit.
    2. Some threads hit the breakpoint.
    3. User switches focus between suspended threads to control them and examine their data.
    b) Threads created/destroyed rapidly
    User is debugging a process with threads being created and destroyed at a rapid rate (more than 1 thread/sec.)
  • II. Multiple processes that interact with each other
  • III. Systems with multiple cores


Problems with workflow

Issues with the user experience when executing the above use cases.


Proposed changes

Proposals for new features and changes in existing workflow.

Comments

Back to the top