Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDT/Obsolete/8.4 Testing"

< CDT‎ | Obsolete
(Tests of new features)
m (Jonah.kichwacoders.com moved page CDT/8.4 Testing to CDT/Obsolete/8.4 Testing)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{warning|Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits.}}
 +
 +
[[Category:CDT:Obsolete]]
 
= Debug tests =
 
= Debug tests =
  
 
== To be run ==
 
== 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.
+
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.
 
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 ===
 
=== Tests of new features ===
'' Dynamic-printf''
+
#Dynamic-printf
 
+
#Showing return value of method after a step-return
''Showing return value of method after a step-return''
+
#Trace Control view enhancements
 
+
#Change breakpoint type
''Trace Control view enhancements''
+
#Opcodes in Disassembly View
 
+
#Tooltip support in Multicore Visualizer
''Change breakpoint type''
+
 
+
''Opcodes in Disassembly View''
+
 
+
''Tooltip support in Multicore Visualizer''
+
  
 
=== Regression tests ===
 
=== Regression tests ===
 
+
#Run DSF-GDB JUnit tests
'''Run DSF-GDB JUnit tests'''
+
#Enhanced Expressions
 
+
#Pretty-printing
'''Enhanced Expressions'''
+
#Process exit code shown in console
 
+
#Edit Tracepoint on Create
'''Pretty-printing'''
+
#Load information in the Multicore Visualizer - CPU/core load meters
 
+
#Multicore Visualizer enhanced selection and filtering
'''Process exit code shown in console'''
+
#Breakpoint Filtering
 
+
#OS Resources View
'''Edit Tracepoint on Create'''
+
#Step Into Selection
 
+
#Synchronization of GDB console
'''Load information in the Multicore Visualizer - CPU/core load meters'''
+
#* Breakpoints, watchpoints and tracepoints
 
+
#* Memory and variables
'''Multicore Visualizer enhanced selection and filtering'''
+
#* Reverse debugging state
 
+
#Breakpoint actions to control reverse debugging
'''Breakpoint Filtering'''
+
#Floating Point renderer of the memory package
 
+
#Debugging multiple processes within one debug session
'''OS Resources View'''
+
#Multicore Visualizer
 
+
#* Run a multi-threaded local debug session
'''Step Into Selection'''
+
#* Verify that threads displayed by creation order in the Debug view
 
+
#* Verify multicore visualizer shows all threads with proper state and coloring
'''Synchronization of GDB console'''
+
#* verify sync with DV is happening
* Breakpoints, watchpoints and tracepoints
+
#* verify drag-select works as expected
* Memory and variables
+
#* verify runcontrol buttons have the right state as different threads are selected
* Reverse debugging state
+
#* perform a multi-thread selection and press resume
 
+
#* verify all selected threads are resumed
'''Breakpoint actions to control reverse debugging'''
+
#* perform a multi-thread selection and press suspend
 
+
#* verify all selected threads are suspended
'''Floating Point renderer of the memory package'''
+
#* 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
'''Debugging multiple processes within one debug session'''
+
#* start a second multi-threaded process
 
+
#* verify that the new threads are shown in the visualizer
'''Multicore Visualizer'''
+
#* select a thread in the new process and press the terminate button in the visualizer
* Run a multi-threaded local debug session
+
#* verify that only the relevant process is removed and the other keeps being debugged and displayed
* Verify multicore visualizer shows all threads with proper state and coloring
+
#* Verify the Multicore Visualizer can display in all-stop mode
* verify sync with DV is happening
+
#Local Debug
* verify drag-select works as expected
+
#* Launch a local debug session in non-stop mode
* verify runcontrol buttons have the right state as different threads are selected
+
#* Verify that stepping works
* perform a multi-thread selection and press resume
+
#* Verify resumes works
* verify all selected threads are resumed
+
#* Verify suspend works
* perform a multi-thread selection and press suspend
+
#* Verify that a breakpoint can be set while the target is running and does interrupt the execution when hit
* verify all selected threads are suspended
+
#* Verify that Run-to-line works in the same method (Ctrl-R)
* verify stepping works from the multicore visualizer when a single suspended thread is selected
+
#* Verify that Run-to-line works in a different method (Ctrl-R)
* verify the context menu has the runControl operations and select all and that they work as expected
+
#* Look at variables view making sure the display is correct
* start a second multi-threaded process
+
#* Look at expressions view making sure the display is correct
* verify that the new threads are shown in the visualizer
+
#* Look at registers view making sure the display is correct
* select a thread in the new process and press the terminate button in the visualizer
+
#* Look at Memory view making sure memory can be displayed correctly
* verify that only the relevant process is removed and the other keeps being debugged and displayed
+
#* Look at Memory Browser view making sure memory can be displayed correctly
**  Sanity tested with GDB 7.5 and works as expected.
+
#* Press the connect button on the Debug view
 
+
#* Press the "New..." button
'''Local Debug'''
+
#* Verify a prompt for a binary comes up
* Launch a local debug session in non-stop mode
+
#* Select a binary
* Verify that stepping works
+
#* Verify that this binary starts being debugged
* Verify resumes works
+
#* Verify that there are two processes being debugged
* Verify suspend works
+
#* Verify that the Debug view shows the cores next to each process and each thread
* Verify that a breakpoint can be set while the target is running and does interrupt the execution when hit
+
#* Verify that monitors created in the Memory view and Memory Browser view only apply to the currently selected process
* Verify that Run-to-line works in the same method (Ctrl-R)
+
#* Verify that changing stack frame will change the content of the Register view for some registers (stack pointer is a good one to check)\
* Verify that Run-to-line works in a different method (Ctrl-R)
+
#Local Attach
* Look at variables view making sure the display is correct
+
#* Launch a local attach session in non-stop mode
* Look at expressions view making sure the display is correct
+
#* Verify that there is a prompt to attach to a process
* Look at registers view making sure the display is correct
+
#* Press the "Cancel" button
* Look at Memory view making sure memory can be displayed correctly
+
#* Verify that the entire launch is terminated without error
* Look at Memory Browser view making sure memory can be displayed correctly
+
#* Start three different long running programs
* Press the connect button on the Debug view
+
#* Launch a local attach session in non-stop mode
* Press the "New..." button
+
#* Verify that there is a prompt to attach to a process
* Verify a prompt for a binary comes up
+
#* Verify that we can select multiple entries in that launch
* Select a binary
+
#* Select the three entries that were started earlier
* Verify that this binary starts being debugged
+
#* Verifies that all three process start being debugged without being interrupted
* Verify that there are two processes being debugged
+
#* Interrupt the second process
* Verify that the Debug view shows the cores next to each process and each thread
+
#* Set a breakpoint in the second process
 
+
#* Resume the second process
'''Local Attach'''
+
#* Verify that the second process stops at the breakpoint
* Launch a local attach session in non-stop mode
+
#* Set a breakpoint in the first process while it is running
* Verify that there is a prompt to attach to a process
+
#* Verify that the first process stops at the breakpoint
* Press the "Cancel" button
+
#* Detach from one process and see that it keeps on running but not debugged
* Verify that the entire launch is terminated without error
+
#* Terminate from one process and see that it is killed
* Start three different long running programs
+
#* Verify only one process is left being debugged
* Launch a local attach session in non-stop mode
+
#* Press the connect button on the Debug view
* Verify that there is a prompt to attach to a process
+
#* Press the "Cancel" button
* Verify that we can select multiple entries in that launch
+
#* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
* Select the three entries that were started earlier
+
#* Press the connect button on the Debug view
* Verifies that all three process start being debugged without being interrupted
+
#* Press the "New..." button
* Interrupt the second process
+
#* Verify a prompt for a binary comes up
* Set a breakpoint in the second process
+
#* Press the "Cancel" button
* Resume the second process
+
#* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
* Verify that the second process stops at the breakpoint
+
#* Press the connect button on the Debug view
* Set a breakpoint in the first process while it is running
+
#* Press the "New..." button
* Verify that the first process stops at the breakpoint
+
#* Verify a prompt for a binary comes up
* Detach from one process and see that it keeps on running but not debugged
+
#* Select a binary
* Terminate from one process and see that it is killed
+
#* Verify that this binary starts being debugged
* Verify only one process is left being debugged
+
#* Verify that there are two processes being debugged
* Press the connect button on the Debug view
+
#Remote Attach
* Press the "Cancel" button
+
#* Start gdbserver --multi :9999
* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
+
#* Launch a remote attach debug session to that target in non-stop mode
* Press the connect button on the Debug view
+
#* Verify the connection is made but nothing else happens
* Press the "New..." button
+
#* Start three long running processes on the target
* Verify a prompt for a binary comes up
+
#* Press the connect button on the Debug view
* Press the "Cancel" button
+
#* Select all three processes started earlier
* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
+
#* Verify there is a prompt for the binary of each process
* Press the connect button on the Debug view
+
#* Verify the title of the prompt shows which binary is being requested
* Press the "New..." button
+
#* Verifies that all three processes start being debugged without being interrupted
* Verify a prompt for a binary comes up
+
#* Interrupt the second process
* Select a binary
+
#* Set a breakpoint in the second process
* Verify that this binary starts being debugged
+
#* Resume the second process
* Verify that there are two processes being debugged
+
#* Verify that the second process stops at the breakpoint
 
+
#* Set a breakpoint in the first process while it is running
'''Remote Attach'''
+
#* Verify that the first process stops at the breakpoint
* Start gdbserver --multi :9999
+
#* Detach from one process and see that it keeps on running but not debugged
* Launch a remote attach debug session to that target in non-stop mode
+
#* Terminate from one process and see that it is killed
* Verify the connection is made but nothing else happens
+
#* Verify only one process is left being debugged
* Start three long running processes on the target
+
#* Press the connect button on the Debug view
* Press the connect button on the Debug view
+
#* Press on "New..."
* Select all three processes started earlier
+
#* Enter the paths of a binary on host and target (same binary) and press "Ok"
* Verify there is a prompt for the binary of each process
+
#* Verify that the binary starts being debugged
* Verify the title of the prompt shows which binary is being requested
+
#Post-mortem Core file
* Verifies that all three processes start being debugged without being interrupted
+
#* Start a local debug session
* Interrupt the second process
+
#* Step or resume to another method of the program
* Set a breakpoint in the second process
+
#* Make sure all threads are interrupted
* Resume the second process
+
#* in the gdb console type 'gcore /tmp/gcore1' to generate a core file
* Verify that the second process stops at the breakpoint
+
#* Start a post-mortem debug session using /tmp/gcore1
* Set a breakpoint in the first process while it is running
+
#* Verify the debug view shows the program stopped where the core file was generated
* Verify that the first process stops at the breakpoint
+
#* Verify all step and resume buttons are grayed out
* Detach from one process and see that it keeps on running but not debugged
+
#* Verify variables are shown in variables view
* Terminate from one process and see that it is killed
+
#* Start a post-mortem debug session leaving the core file field empty
* Verify only one process is left being debugged
+
#* Verify a prompt for a core file is displayed
* Press the connect button on the Debug view
+
#* Press the "Cancel" button
* Press on "New..."
+
#* Verify that the entire launch is terminated without error
* Enter the paths of a binary on host and target (same binary) and press "Ok"
+
#* Start a post-mortem debug session leaving the core file field empty
* Verify that the binary starts being debugged
+
#* Verify a prompt for a core file is displayed
 
+
#* select /tmp/gcore1
'''Post-mortem Core file'''
+
#* Verify the core file starts being 'debugged' as it was in the previous attempt
* Start a local debug session
+
#* Start a post-mortem debug session only putting /tmp is the core file field
* Step or resume to another method of the program
+
#* Verify a prompt for a core file is displayed starting in /tmp
* Make sure all threads are interrupted
+
#* select gcore1
* in the gdb console type 'gcore /tmp/gcore1' to generate a core file
+
#* Verify the core file starts being 'debugged' as it was in the previous attempt
* Start a post-mortem debug session using /tmp/gcore1
+
#Automatic Remote Debug
* Verify the debug view shows the program stopped where the core file was generated
+
#* Start an Automatic Remote debug session
* Verify all step and resume buttons are grayed out
+
#* verify the process is being debugged
* Verify variables are shown in variables view
+
#Manual Remote Debug
* Start a post-mortem debug session leaving the core file field empty
+
#* Start gdbserver (without --multi) with a binary
* Verify a prompt for a core file is displayed
+
#* Start an Manual Remote debug session to that target
* Press the "Cancel" button
+
#* verify the process is being debugged
* Verify that the entire launch is terminated without error
+
#Tracepoints tests
* Start a post-mortem debug session leaving the core file field empty
+
#* Launch an Automatic Remote Debug session in Non-stop mode
* Verify a prompt for a core file is displayed
+
#* Create two tracepoints in the editor
* select /tmp/gcore1
+
#* Add the following actions to the first tracepoint: 'collect $locals' and 'collect $reg'
* Verify the core file starts being 'debugged' as it was in the previous attempt
+
#* Add the following actions to the second tracepoint: 'collect $trace_timestamp' and 'collect <single local var>'
* Start a post-mortem debug session only putting /tmp is the core file field
+
#* Start trace experiment
* Verify a prompt for a core file is displayed starting in /tmp
+
#* Resume program execution
* select gcore1
+
#* Wait until trace data is collected (look at Trace Control view)
* Verify the core file starts being 'debugged' as it was in the previous attempt
+
#* Stop trace experiment
 
+
#* Save trace data using Trace Control view view-menu
'''Automatic Remote Debug'''
+
#* In the Trace Control view, press the Next Record button and navigate through the collected records
* Start an Automatic Remote debug session
+
#* Look at Variables view and Debug view to see that the collected data is properly displayed
* verify the process is being debugged
+
#* 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
'''Manual Remote Debug'''
+
#* In the Trace Control view, press the Next Record button and navigate through the collected records
* Start gdbserver (without --multi) with a binary
+
#* Look at Variables view and Debug view to see that the collected data is properly displayed
* Start an Manual Remote debug session to that target
+
#* Make sure that unavailable data shows "<unavailable>" in the Variables view
* verify the process is being debugged
+
#* 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
'''Tracepoints tests'''
+
#* Select the trace data file saved in the previous test case
* Launch an Automatic Remote Debug session in Non-stop mode
+
#* In the Trace Control view, press the Next Record button and navigate through the collected records
* Create two tracepoints in the editor
+
#* Look at Variables view and Debug view to see that the collected data is properly displayed
* Add the following actions to the first tracepoint: 'collect $locals' and 'collect $reg'
+
#* Make sure that unavailable data shows "<unavailable>" in the Variables view
* Add the following actions to the second tracepoint: 'collect $trace_timestamp' and 'collect <single local var>'
+
#* Launch a Post-mortem Tracing debug session having the trace data field only contain a directory
* Start trace experiment
+
#* Verify a prompt for a trace file is displayed starting in the specified directory
* Resume program execution
+
#Fast Tracepoint tests
* Wait until trace data is collected (look at Trace Control view)
+
#* create two tracepoints in the same program
* Stop trace experiment
+
#* Launch an automatic remote debug session in non-stop with the fast tracepoint option
* Save trace data using Trace Control view view-menu
+
#* verify that only fast tracepoint are created, or no tracepoint if a fast tp cannot be created
* In the Trace Control view, press the Next Record button and navigate through the collected records
+
#* verify that tracepoints are shown properly in the Disassembly view
* Look at Variables view and Debug view to see that the collected data is properly displayed
+
#* Launch an automatic remote debug session in non-stop with the normal tracepoint option
* Make sure that unavailable data shows "<unavailable>" in the Variables view
+
#* verify that only two normal tracepoint are created
* Launch a Post-mortem Tracing debug session using the trace data file saved in the previous test case
+
#* verify that tracepoints are shown properly in the Disassembly view
* In the Trace Control view, press the Next Record button and navigate through the collected records
+
#* Launch an automatic remote debug session in non-stop with the automatic tracepoint option
* Look at Variables view and Debug view to see that the collected data is properly displayed
+
#* verify that fast tracepoints are created, or normal tracepoint if a fast tp cannot be created
* Make sure that unavailable data shows "<unavailable>" in the Variables view
+
#* verify that tracepoints are shown properly in the Disassembly view
* Launch a Post-mortem Tracing debug session leaving the trace data field empty
+
#* delete and re-create the tracepoints directly in the Disassembly view
* Verify that a prompt is displayed to select the trace data file
+
#* verify the breakpoints are created in GDB as expected
* Select the trace data file saved in the previous test case
+
#Reverse Debugging
* In the Trace Control view, press the Next Record button and navigate through the collected records
+
#* Launch a local debug session in all-stop mode (reverse debugging is not supported in non-stop)
* Look at Variables view and Debug view to see that the collected data is properly displayed
+
#* Customize the perspective to show the reverse debugging toggle button
* Make sure that unavailable data shows "<unavailable>" in the Variables view
+
#* Verify that the button appears on the global toolbar or the debug view toolbar (depending on your settings)
* Launch a Post-mortem Tracing debug session having the trace data field only contain a directory
+
#* Toggle reverse debugging
* Verify a prompt for a trace file is displayed starting in the specified directory
+
#* Verify the reverse debugging buttons for reverse and step appear properly
 
+
#* Do some forward and reverse debugging
'''Fast Tracepoint tests'''
+
#* Verify that stepping works properly both ways
* create two tracepoints in the same program
+
#* Verify resumes works properly both ways
* 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 ==
 
== Completed ==
 
The below tests have been completed.  Any issues found is indicated below the test entry.
 
The below tests have been completed.  Any issues found is indicated below the test entry.

Latest revision as of 14:15, 16 January 2020

Warning2.png
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. 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

  1. Dynamic-printf
  2. Showing return value of method after a step-return
  3. Trace Control view enhancements
  4. Change breakpoint type
  5. Opcodes in Disassembly View
  6. Tooltip support in Multicore Visualizer

Regression tests

  1. Run DSF-GDB JUnit tests
  2. Enhanced Expressions
  3. Pretty-printing
  4. Process exit code shown in console
  5. Edit Tracepoint on Create
  6. Load information in the Multicore Visualizer - CPU/core load meters
  7. Multicore Visualizer enhanced selection and filtering
  8. Breakpoint Filtering
  9. OS Resources View
  10. Step Into Selection
  11. Synchronization of GDB console
    • Breakpoints, watchpoints and tracepoints
    • Memory and variables
    • Reverse debugging state
  12. Breakpoint actions to control reverse debugging
  13. Floating Point renderer of the memory package
  14. Debugging multiple processes within one debug session
  15. 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
  16. 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)\
  17. 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
  18. 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
  19. 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
  20. Automatic Remote Debug
    • Start an Automatic Remote debug session
    • verify the process is being debugged
  21. 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
  22. 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
  23. 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
  24. 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.

Back to the top