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.
CDT/Obsolete/8.4 Testing
Contents
Debug tests
To be run
The below tests have not be run yet. Once run, they can be moved to the 'completed' section below. Please indicate with which build each section of tests was performed. 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.
Tests of new features
- Dynamic-printf
- Showing return value of method after a step-return
- Trace Control view enhancements
- Change breakpoint type
- Opcodes in Disassembly View
- Tooltip support in Multicore Visualizer
Regression tests
- Run DSF-GDB JUnit tests
- Enhanced Expressions
- Pretty-printing
- Process exit code shown in console
- Edit Tracepoint on Create
- Load information in the Multicore Visualizer - CPU/core load meters
- Multicore Visualizer enhanced selection and filtering
- Breakpoint Filtering
- OS Resources View
- Step Into Selection
- 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
- Multicore Visualizer
- Run a multi-threaded local debug session
- Verify that threads displayed by creation order in the Debug view
- 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
- Verify the Multicore Visualizer can display in all-stop mode
- 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
- Verify that monitors created in the Memory view and Memory Browser view only apply to the currently selected process
- Verify that changing stack frame will change the content of the Register view for some registers (stack pointer is a good one to check)\
- 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
- 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
- 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
- Automatic Remote Debug
- Start an Automatic Remote debug session
- verify the process is being debugged
- 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
- 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
- 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
- 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
Completed
The below tests have been completed. Any issues found is indicated below the test entry.