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.
Difference between revisions of "CDT/Archive/cdt-debug-dsf-gdb"
m (→Features) |
m (→Test 7: Invalid condition propagation) |
||
Line 369: | Line 369: | ||
==== Test 7: Invalid condition propagation ==== | ==== Test 7: Invalid condition propagation ==== | ||
− | *# Change to an | + | *# Change to an ''invalid'' condition |
*#* ''Check:'' Updates failed | *#* ''Check:'' Updates failed | ||
*#* ''Check:'' Breakpoints aren't changed (previous valid condition is kept) | *#* ''Check:'' Breakpoints aren't changed (previous valid condition is kept) |
Revision as of 20:50, 5 January 2009
Contents
- 1 Overview
- 2 Features
- 3 Manual Test Procedures
- 3.1 GDB Basic Sanity Test
- 3.2 Launching
- 3.3 Line Breakpoints (General)
- 3.4 Watchpoints (General)
- 3.4.1 Test Setup
- 3.4.2 Test 1: Watchpoint setting
- 3.4.3 Test 2: Watchpoint activation
- 3.4.4 Test 3: Watchpoint condition
- 3.4.5 Test 4: Watchpoint ignore count
- 3.4.6 Test 5: Watchpoint deletion (simple)
- 3.4.7 Test 6: Watchpoint persistence
- 3.4.8 Test 7: Import/export watchpoints to file
- 3.4.9 Test 8: Watchpoint deletion (multiple)
- 3.5 Skip All (Breakpoints) Button
- 3.6 Breakpoint Thread Filters
- 3.6.1 Test Setup
- 3.6.2 Test 1: Filter out a thread
- 3.6.3 Test 2: Filtered thread substitution
- 3.6.4 Test 3: Remove a filtered thread
- 3.6.5 Test 4: Add a filtered thread
- 3.6.6 Test 5: Remove thread filters
- 3.6.7 Test 6: Initial state propagation
- 3.6.8 Test 7: Invalid condition propagation
- 3.6.9 Test 8: Valid condition propagation
- 3.6.10 Test 9: Condition/Ignore count removal propagation
- 3.6.11 Test 10: State persistence
- 3.6.12 Test 11: Simultaneous update of state and thread filter
- 3.6.13 Test 12: Addition of thread filter, invalid condition and ignore count
- 3.6.14 Test 13: Enable, disable breakpoints
Overview
Features
Version support
- GDB 6.7+
Launching
- Launch Configurations
- Launch an application on local host
- Attach to a running process
- Launch an application on a remote host
- GDB Debugger options
- Non-stop mode selection
CDT Breakpoints Support
Non-stop mode multi-threaded debugging support
Multi-process Debugging
CLI Console
Manual Test Procedures
GDB Basic Sanity Test
- Check out and build the sanity test project from /cvsroot/dsdp/org.eclipse.dd.dsf/tests/SanityTest
- Launch the DSF debugger with break at main
- Follow instructions in the test.
Launching
- Perspective
- In Preferences->Run/Debug->Perspectives, make sure that at least one perspective change option is set to prompt.
- Set the java or c++ perspective
- Launch a DSF program
- Verify that there is a prompt to switch perspective to Debug, Answer yes
- Verify the perspective switches
- Expanding after launch
- Verify from the above test that the Debug view has a selection to the top-most thread
- Close Debug view
- Open Debug view
- Verify that the Debug view has a selection to the top-most thread
- Break on main
- Set a valid break-on-main symbol, and launch.
- Check: the program breaks at the correct location.
- Set an invalid break-on-main symbol, and launch.
- Check: the launch should fail with an error from creating the break-on-main breakpoint
- Set a break-on-main symbol that is not reachable by the program, but the program continues running, and launch.
- Check: the launch should complete as if there was no break-on-main symbol set.
- Set a break-on-main symbol that is not reachable by the program, but and the program exits quickly.
- Check: the launch should complete and the program should run and terminate normally.
- Set a valid break-on-main symbol, and launch.
- Remote Launch
- Start a gdbserver session with the binary of the eclipse C++ project
- Use the DSF Remote launch to connect to that gdbserver
- Verify that the debugging session is the same as a local debugging session
- Verify that the Restart button is grayed out
- Local Attach Launch
- Start the binary of your project outside of eclipse (this binary should take a long time to execute to give you enough time to attach to it)
- Use the DSF Attach to Local applicaiton launch
- Verify that a popup window prompts for the process to attach to
- Select the binary you started
- Verify that the debugging session is the same as a local debugging session
- Verify that the Restart button is grayed out
- Verify that the output of the binary remains on the terminal where it was started
- Remote Attach Launch
- Start a gdbserver session with the --multi flag and no binary
- Start the binary of your project outside of eclipse (this binary should take a long time to execute to give you enough time to attach to it)
- Use the DSF Attach launch to connect to that gdbserver using the 'gdbserver Debugger' type
- Verify that a popup window prompts for the process pid to attach to (no list)
- Put in the pid of the binary you started
- Verify that the debugging session is the same as a local debugging session
- Verify that the Restart button is grayed out
- Verify that the output of the binary remains on the terminal where it was started
- Output
- Launch a local debug session
- Step the program to execute a couple of instructions that have a printf
- Verify that the output of the program is properly seen in a separate console.
- Restart
- Launch a local debug session
- Step the program to execute a couple of instructions
- Press the Restart button and verify that the program restarts from the beginning
- Verify also that the "Break on main option is still respected on the restart
- Verify also that the output of the program is properly seen in a separate console.
Line Breakpoints (General)
Test Setup
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Start a DSF debug session (DsfBreakpoints)
Test 1: Breakpoint setting
- In the editor, add a new line breakpoint (BP-1)
- Check: A new breakpoint is inserted and it is enabled
- In the view menu: enable the "Show Full Paths" check box
- Check: The breakpoint full path is displayed in the view
- In the editor, disable the "Show Full Paths" check box
- Check: The breakpoint full path is not displayed in the view
- In the editor, add a new line breakpoint (BP-1)
Test 2: Breakpoint activation
- In the editor, disable BP-1
- Check: BP-1 is disabled
- In the editor, enable BP-1
- Check: BP-1 is enabled
- From the breakpoint context menu, disable BP-1
- Check: BP-1 is disabled
- From the breakpoint context menu, enable BP-1
- Check: BP-1 is enabled
- In the editor, disable BP-1
Test 3: Breakpoint condition
- Set an invalid condition on BP-1
- Check: The update is rejected and BP-1 is not changed
- Set a valid condition on BP-1
- Check: The update is accepted and BP-1 has the new condition
- Set an invalid condition on BP-1
- Check: The update is rejected and BP-1 kept the valid condition
- Clear the BP-1 condition
- Check: The update is accepted and BP-1 no longer has a condition
- Set an invalid condition on BP-1
Test 4: Breakpoint ignore count
- Set an ignore count on BP-1
- Check: The update is accepted and BP-1 has the new ignore count
- Reset an ignore count on BP-1 (set to 0)
- Check: The update is accepted and BP-1 has no ignore count
- Set an ignore count on BP-1
- Test 5: Breakpoint deletion (simple)
- From the GUI, delete BP-1
- Check: BP-1 is removed
- From the GUI, delete BP-1
Test 6: Breakpoint persistence
- Create 4 breakpoints with the following characteristics:
- BP-1: enabled, no condition, no ignore count
- BP-2: disabled, with condition, no ignore count
- BP-3: disabled, no condition, with ignore count
- BP-4: enabled, with condition, with ignore count
- Check: The 4 breakpoints are correctly created
- Terminate the debugging session
- Start a new debugging session
- Check: The 4 breakpoints are correctly restored
- Terminate the debugging session
- Enable all breakpoints
- Start a new debugging session
- Check: The 4 breakpoints are correctly restored (and enabled)
- Create 4 breakpoints with the following characteristics:
Test 7: Import/export breakpoints to file
- Create 4 breakpoints with the following characteristics (re-use the ones from previous step):
- BP-1: enabled, no condition, no ignore count
- BP-2: disabled, with condition, no ignore count
- BP-3: disabled, no condition, with ignore count
- BP-4: enabled, with condition, with ignore count
- Check: The 4 breakpoints are correctly created
- Export the 4 breakpoints to file
- Check: The breakpoints file is created
- Remove all breakpoints
- Check: The 4 breakpoints are removed
- Import the breakpoint file
- Check: The 4 breakpoints are correctly restored
- Remove all breakpoints
- Terminate the debugging session
- Start a new debugging session
- Check: No breakpoint is installed
- Import the breakpoint file
- Check: The 4 breakpoints are correctly restored
- Create 4 breakpoints with the following characteristics (re-use the ones from previous step):
Test 8: Breakpoint deletion (multiple)
- From the GUI, delete BP-1, BP-2, BP-3 and BP-4
- Check: the 4 breakpoints are removed
- From the GUI, delete BP-1, BP-2, BP-3 and BP-4
Watchpoints (General)
Test Setup
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Start a DSF debug session (DsfBreakpoints)
Test 1: Watchpoint setting
- In the Breakpoint View, add a new watchpoint (WP-1)
- Check: A new watchpoint is inserted and it is enabled
- In the Breakpoint View, add a new watchpoint (WP-1)
Test 2: Watchpoint activation
- From the watchpoint context menu. disable WP-1
- Check: WP-1 is disabled
- From the watchpoint context menu, enable WP-1
- Check: WP-1 is enabled
- From the watchpoint context menu. disable WP-1
Test 3: Watchpoint condition
- Set an invalid condition on WP-1
- Check: The update is rejected and WP-1 is not changed
- Set a valid condition on WP-1
- Check: The update is accepted and WP-1 has the new condition
- Set an invalid condition on WP-1
- Check: The update is rejected and WP-1 kept the valid condition
- Clear the WP-1 condition
- Check: The update is accepted and WP-1 no longer has a condition
- Set an invalid condition on WP-1
Test 4: Watchpoint ignore count
- Set an ignore count on WP-1
- Check: The update is accepted and WP-1 has the new ignore count
- Reset an ignore count on WP-1 (set to 0)
- Check: The update is accepted and WP-1 has no ignore count
- Set an ignore count on WP-1
Test 5: Watchpoint deletion (simple)
- From the GUI, delete WP-1
- Check: WP-1 is removed
- From the GUI, delete WP-1
Test 6: Watchpoint persistence
- Create 4 watchpoints with the following characteristics:
- WP-1 enabled, write, no condition, no ignore count
- WP-2 disabled, read, with condition, no ignore count
- WP-3 disabled, read/write, no condition, with ignore count
- WP-4 enabled, write, with condition, with ignore count
- Check: The 4 watchpoints are correctly created
- Terminate the debugging session
- Start a new debugging session
- Check: The 4 watchpoints are correctly restored
- Terminate the debugging session
- Enable all watchpoints
- Start a new debugging session
- Check: The 4 watchpoints are correctly restored (and enabled)
- Create 4 watchpoints with the following characteristics:
Test 7: Import/export watchpoints to file
- Create 4 watchpoints with the following characteristics (re-use watchpoints from previous step):
- WP-1 enabled, write, no condition, no ignore count
- WP-2 disabled, read, with condition, no ignore count
- WP-3 disabled, read/write, no condition, with ignore count
- WP-4 enabled, write, with condition, with ignore count
- Check: The 4 watchpoints are correctly created
- Export the 4 watchpoints to file
- Check: The watchpoints file is created
- Remove all watchpoints
- Check: The 4 watchpoints are removed
- Import the watchpoints file
- Check: The 4 watchpoints are correctly restored
- Remove all watchpoints
- Terminate the debugging session
- Start a new debugging session
- Check: No watchpoints is installed
- Import the watchpoints file
- Check: The 4 watchpoints are correctly restored
- Create 4 watchpoints with the following characteristics (re-use watchpoints from previous step):
Test 8: Watchpoint deletion (multiple)
- From the GUI, delete WP-1, WP-2, WP-3 and WP-4
- Check: The 4 watchpoints are removed
- From the GUI, delete WP-1, WP-2, WP-3 and WP-4
Skip All (Breakpoints) Button
Test Setup
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Create 3 line breakpoints (anything will do)
- Start a DSF debug session (DsfBreakpoints)
- Check: Breakpoints are created and enabled
Test 1: Simple ON/OFF
- Toggle the 'Skip All Button' SAB to ON
- Check: BPs 1, 2, 3 are disabled
- Toggle the SAB to OFF
- Check: BPs 1, 2, 3 are enabled
- Toggle the 'Skip All Button' SAB to ON
Test 2: ON/OFF with some disabled BPs
- Disable BP 2
- Check: Only BP-2 is disabled
- Toggle the SAB to ON
- Check: All breakpoints are disabled
- Toggle the SAB to OFF
- Check: BPs 1, 3 are enabled
- Disable BP 1 and 3
- Enable BP 2
- Check: Only BP-2 is enabled
- Toggle the SAB to ON
- Check: All breakpoints are disabled
- Toggle the SAB to OFF
- Check: Only BP-2 is enabled
- Disable BP 2
Test 3: ON/OFF with all BPs disabled
- Disable BPs 1, 2, 3
- Toggle the SAB to ON
- Check: Nothing happens
- Toggle the SAB to OFF
- Check: Nothing happens
Test 4: Change BPs state while OFF
- Enable BP 2
- Disable BPs 1, 3
- Toggle the SAB to ON
- Check: BP 2 is disabled
- Enable BP 1
- Check: Nothing happens
- Disable BP 2
- Check: Nothing happens
- Toggle the SAB to OFF
- Check: BP 1 is enabled
Test 6: Startup
- Terminate DSF debug session
- Enable BPs 1, 2, 3
- Toggle the SAB to ON
- Start DSF debug session
- Check: BPs 1, 2, 3 are created and disabled
- Toggle the SAB to OFF
- Check: BPs 1, 2, 3 are enabled
Breakpoint Thread Filters
Test Setup
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Create a breakpoint on the return statement of the printMsg function ("return NULL")
- Start a DSF debug session (DsfThreads)
- Check: Breakpoint is created and enabled
- Run to breakpoint
- Check: There are 3 threads (1, 2 and 3) in the Debug View
Test 1: Filter out a thread
- Set filter for threads 1, 2
- Check: The original breakpoint is removed
- Check: 2 identical breakpoints are installed, one for each thread selected
- Set filter for threads 1, 2
Test 2: Filtered thread substitution
- Change filter for threads 1, 3
- Check: The breakpoint for thread 2 is removed
- Check: 2 identical breakpoints are installed, one for each thread selected
- Change filter for threads 1, 3
Test 3: Remove a filtered thread
- Change filter for thread 2 only
- Check: The breakpoints for threads 1, 3 are removed
- Check: A breakpoint is installed for thread 2
- Change filter for thread 2 only
Test 4: Add a filtered thread
- Change filter for thread 2, 3
- Check: 2 identical breakpoints are installed, one for each thread selected
- Change filter for thread 2, 3
Test 5: Remove thread filters
- Remove filter
- Check: The breakpoints for threads 2, 3 are removed
- Check: A new breakpoint is set with no thread filter
- Remove filter
Test 6: Initial state propagation
- Add a valid condition and ignore count to the breakpoint
- Check: The breakpoint is updated
- Add filter for threads 1, 2
- Check: The original breakpoint is removed
- Check: 2 new breakpoints are set with the correct condition, ignore count, one for each thread selected
- Add a valid condition and ignore count to the breakpoint
Test 7: Invalid condition propagation
- Change to an invalid condition
- Check: Updates failed
- Check: Breakpoints aren't changed (previous valid condition is kept)
- Change to an invalid condition
Test 8: Valid condition propagation
- Add a valid condition
- Check: Condition is properly set for both breakpoints
- Add a valid condition
Test 9: Condition/Ignore count removal propagation
- Remove condition and ignore count
- Check: Condition and ignore count are removed from both breakpoints
- Remove condition and ignore count
Test 10: State persistence
- Add a valid condition, ignore count
- Check: Condition/Ignore count are properly set for both breakpoints
- Remove thread filter
- Check: The breakpoints for threads 1, 2 are removed
- Check: A new breakpoint is set with the correct condition, ignore count and no thread filter
- Add a valid condition, ignore count
Test 11: Simultaneous update of state and thread filter
- Add filter for threads 1, 2, a valid condition and an ignore count
- Check: The original breakpoint is removed
- Check: 2 new breakpoints are set with proper ignore count, condition
- Remove thread filter
- Check: The breakpoints for threads 1, 2 are removed
- Check: A new breakpoint is set with the correct condition, ignore count and no thread filter
- Add filter for threads 1, 2, a valid condition and an ignore count
Test 12: Addition of thread filter, invalid condition and ignore count
- Add filter for threads 1, 2, invalid condition, ignore count
- Check: The original breakpoint is removed
- Check: 2 new breakpoints are set with proper ignore count and old (valid) condition
- Remove thread filter
- Check: The breakpoints for threads 1, 2 are removed
- Check: A new breakpoint is set with the correct condition, ignore count and no thread filter
- Add filter for threads 1, 2, invalid condition, ignore count
Test 13: Enable, disable breakpoints
- Disable the breakpoint
- Check: The breakpoint is disabled
- Add filter for threads 1, 2
- Check: The original breakpoint is removed
- Check: 2 new disabled breakpoints are set with proper ignore count, condition
- Enable the breakpoint
- Check: Both back-end breakpoints are enabled
- Remove thread filter
- Check: The breakpoints for threads 1, 2 are removed
- Check: A new (enabled) breakpoint is set with the correct condition, ignore count and no thread filter
- Disable the breakpoint