CDT/Obsolete/8.2 RC1 Testing

Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits.

Debug tests

To be run

The below tests have not be run yet. Once run, they can be moved to the 'completed' section below. These tests are suggestions of what should be tested, but are not exhaustive.

When someone decides to run some tests, they should put their name next to the section selected. This will avoid multiple people running the same tests.

Completed

The below tests have been completed. Any issues found is indicated below the test entry.

Tests of new features

Enhanced Expressions

• Sanity tested with GDB 7.6 and works as expected.

Pretty-printing

• Sanity tested with GDB 7.5 and works as expected.

Process exit code shown in console

• Sanity tested with GDB 7.6 and working as expected

Edit Tracepoint on Create

• Sanity tested with GDB 7.6 and working as expected in Editor and Disassembly view

Load information in the Multicore Visualizer - CPU/core load meters

• Sanity tested with GDB 7.5 and works as expected.

Multicore Visualizer enhanced selection and filtering

• Bug 407673 - [visualizer] canvas filter on thread: sometimes wrongly hides thread
• Sanity tested with GDB 7.5 and otherwise works as expected.

Breakpoint Filtering

• Sanity tested with GDB 7.6 and working as expected

OS Resources View

• Sanity tested with GDB 7.6 and working as expected

Step Into Selection

• Sanity tested with GDB 7.5 and working as expected

Synchronization of GDB console

• Breakpoints, watchpoints and tracepoints
• Memory and variables
• Reverse debugging state

Breakpoint actions to control reverse debugging

Floating Point renderer of the memory package

Debugging multiple processes within one debug session

Regression tests

Run DSF-GDB JUnit tests

All tests pass for the local case (see Bug 409186)

Multicore Visualizer

• Run a multi-threaded local debug session
• Verify multicore visualizer shows all threads with proper state and coloring
• verify sync with DV is happening
• verify drag-select works as expected
• verify runcontrol buttons have the right state as different threads are selected
• perform a multi-thread selection and press resume
• verify all selected threads are resumed
• perform a multi-thread selection and press suspend
• verify all selected threads are suspended
• verify stepping works from the multicore visualizer when a single suspended thread is selected
• verify the context menu has the runControl operations and select all and that they work as expected
• start a second multi-threaded process
• verify that the new threads are shown in the visualizer
• select a thread in the new process and press the terminate button in the visualizer
• verify that only the relevant process is removed and the other keeps being debugged and displayed
  • Sanity tested with GDB 7.5 and works as expected.

Local Debug

• Launch a local debug session in non-stop mode
• Verify that stepping works
• Verify resumes works
• Verify suspend works
• Verify that a breakpoint can be set while the target is running and does interrupt the execution when hit
• Verify that Run-to-line works in the same method (Ctrl-R)
• Verify that Run-to-line works in a different method (Ctrl-R)
• Look at variables view making sure the display is correct
• Look at expressions view making sure the display is correct
• Look at registers view making sure the display is correct
• Look at Memory view making sure memory can be displayed correctly
• Look at Memory Browser view making sure memory can be displayed correctly
• Press the connect button on the Debug view
• Press the "New..." button
• Verify a prompt for a binary comes up
• Select a binary
• Verify that this binary starts being debugged
• Verify that there are two processes being debugged
• Verify that the Debug view shows the cores next to each process and each thread
  • Sanity tested with GDB 7.5 and works as expected.

Local Attach

• Launch a local attach session in non-stop mode
• Verify that there is a prompt to attach to a process
• Press the "Cancel" button
• Verify that the entire launch is terminated without error
• Start three different long running programs
• Launch a local attach session in non-stop mode
• Verify that there is a prompt to attach to a process
• Verify that we can select multiple entries in that launch
• Select the three entries that were started earlier
• Verifies that all three process start being debugged without being interrupted
• Interrupt the second process
• Set a breakpoint in the second process
• Resume the second process
• Verify that the second process stops at the breakpoint
• Set a breakpoint in the first process while it is running
• Verify that the first process stops at the breakpoint
• Detach from one process and see that it keeps on running but not debugged
• Terminate from one process and see that it is killed
• Verify only one process is left being debugged
• Press the connect button on the Debug view
• Press the "Cancel" button
• Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
• Press the connect button on the Debug view
• Press the "New..." button
• Verify a prompt for a binary comes up
• Press the "Cancel" button
• Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
• Press the connect button on the Debug view
• Press the "New..." button
• Verify a prompt for a binary comes up
• Select a binary
• Verify that this binary starts being debugged
• Verify that there are two processes being debugged
  • Bug 409512 - [visualizer] Threads not cleaned-up after process detached
  • Sanity tested with GDB 7.5 and otherwise works as expected.

Remote Attach

• Start gdbserver --multi :9999
• Launch a remote attach debug session to that target in non-stop mode
• Verify the connection is made but nothing else happens
• Start three long running processes on the target
• Press the connect button on the Debug view
• Select all three processes started earlier
• Verify there is a prompt for the binary of each process
• Verify the title of the prompt shows which binary is being requested
• Verifies that all three processes start being debugged without being interrupted
• Interrupt the second process
• Set a breakpoint in the second process
• Resume the second process
• Verify that the second process stops at the breakpoint
• Set a breakpoint in the first process while it is running
• Verify that the first process stops at the breakpoint
• Detach from one process and see that it keeps on running but not debugged
• Terminate from one process and see that it is killed
• Verify only one process is left being debugged
• Press the connect button on the Debug view
• Press on "New..."
• Enter the paths of a binary on host and target (same binary) and press "Ok"
• Verify that the binary starts being debugged
  • Sanity tested with GDB 7.5 and works as expected.

Post-mortem Core file

• Start a local debug session
• Step or resume to another method of the program
• Make sure all threads are interrupted
• in the gdb console type 'gcore /tmp/gcore1' to generate a core file
• Start a post-mortem debug session using /tmp/gcore1
• Verify the debug view shows the program stopped where the core file was generated
• Verify all step and resume buttons are grayed out
• Verify variables are shown in variables view
• Start a post-mortem debug session leaving the core file field empty
• Verify a prompt for a core file is displayed
• Press the "Cancel" button
• Verify that the entire launch is terminated without error
• Start a post-mortem debug session leaving the core file field empty
• Verify a prompt for a core file is displayed
• select /tmp/gcore1
• Verify the core file starts being 'debugged' as it was in the previous attempt
• Start a post-mortem debug session only putting /tmp is the core file field
• Verify a prompt for a core file is displayed starting in /tmp
• select gcore1
• Verify the core file starts being 'debugged' as it was in the previous attempt
  • Sanity tested with GDB 7.6 and works as expected.

Automatic Remote Debug

• Start an Automatic Remote debug session
• verify the process is being debugged
  • Sanity tested with GDB 7.5 and works as expected.

Manual Remote Debug

• Start gdbserver (without --multi) with a binary
• Start an Manual Remote debug session to that target
• verify the process is being debugged
  • Sanity tested with GDB 7.5 and works as expected.

Tracepoints tests

• Launch an Automatic Remote Debug session in Non-stop mode
• Create two tracepoints in the editor
• Add the following actions to the first tracepoint: 'collect $locals' and 'collect $reg'
• Add the following actions to the second tracepoint: 'collect $trace_timestamp' and 'collect <single local var>'
• Start trace experiment
• Resume program execution
• Wait until trace data is collected (look at Trace Control view)
• Stop trace experiment
• Save trace data using Trace Control view view-menu
• In the Trace Control view, press the Next Record button and navigate through the collected records
• Look at Variables view and Debug view to see that the collected data is properly displayed
• Make sure that unavailable data shows "<unavailable>" in the Variables view
• Launch a Post-mortem Tracing debug session using the trace data file saved in the previous test case
• In the Trace Control view, press the Next Record button and navigate through the collected records
• Look at Variables view and Debug view to see that the collected data is properly displayed
• Make sure that unavailable data shows "<unavailable>" in the Variables view
• Launch a Post-mortem Tracing debug session leaving the trace data field empty
• Verify that a prompt is displayed to select the trace data file
• Select the trace data file saved in the previous test case
• In the Trace Control view, press the Next Record button and navigate through the collected records
• Look at Variables view and Debug view to see that the collected data is properly displayed
• Make sure that unavailable data shows "<unavailable>" in the Variables view
• Launch a Post-mortem Tracing debug session having the trace data field only contain a directory
• Verify a prompt for a trace file is displayed starting in the specified directory
  • Sanity tested with GDB 7.5 and works as expected.

Fast Tracepoint tests

• create two tracepoints in the same program
• Launch an automatic remote debug session in non-stop with the fast tracepoint option
• verify that only fast tracepoint are created, or no tracepoint if a fast tp cannot be created
• verify that tracepoints are shown properly in the Disassembly view
• Launch an automatic remote debug session in non-stop with the normal tracepoint option
• verify that only two normal tracepoint are created
• verify that tracepoints are shown properly in the Disassembly view
• Launch an automatic remote debug session in non-stop with the automatic tracepoint option
• verify that fast tracepoints are created, or normal tracepoint if a fast tp cannot be created
• verify that tracepoints are shown properly in the Disassembly view
• delete and re-create the tracepoints directly in the Disassembly view
• verify the breakpoints are created in GDB as expected
  • Sanity tested with GDB 7.5 and works as expected.

Reverse Debugging

• Launch a local debug session in all-stop mode (reverse debugging is not supported in non-stop)
• Customize the perspective to show the reverse debugging toggle button
• Verify that the button appears on the global toolbar or the debug view toolbar (depending on your settings)
• Toggle reverse debugging
• Verify the reverse debugging buttons for reverse and step appear properly
• Do some forward and reverse debugging
• Verify that stepping works properly both ways
• Verify resumes works properly both ways
  • Sanity tested with GDB 7.6 and works as expected except that the position of the reverse debugging buttons seems to have changed. Need to see if something changed in platform debug.