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.1 RC3 Testing"

< CDT‎ | Obsolete
m (Jonah.kichwacoders.com moved page CDT/8.1 RC3 Testing to CDT/Obsolete/8.1 RC3 Testing)
 
(No difference)

Latest revision as of 14:14, 16 January 2020

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

Debug tests

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

Run DSF-GDB JUnit tests

  • Ran the local tests for 7.4 and 7.5 (with latest GDB HEAD).
Got one single error, but it was a timeout in a *WhileRunning tests, which intermittently fails.  
Also ran the remote tests for 7.4 with the 2 intermittent failures:
  updateCatchpoint_WhileTargetRunning1 and updateCatchpoint_WhileTargetRunning2
  and 1 expected failure in the getExecutionContexts test (will open a bug)

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

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
  • Verify the "New..." button is grayed out (not available)

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

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

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
Got this assertion, probably from the Multicore Visualizer:
Uncaught exception in session executor thread: java.lang.AssertionError: Exception thrown by a IServiceEventListener.ServiceHandlerMethod method
       at org.eclipse.cdt.dsf.service.DsfSession.doDispatchEvent(DsfSession.java:529)
       at org.eclipse.cdt.dsf.service.DsfSession.access$2(DsfSession.java:463)
       at org.eclipse.cdt.dsf.service.DsfSession$3.run(DsfSession.java:390)
       at org.eclipse.cdt.dsf.concurrent.DefaultDsfExecutor$TracingWrapperRunnable.run(DefaultDsfExecutor.java:374)
When I disabled -ea, things worked ok.  Will open a bug.
  • 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
For postmortem files, the breakpoints view does not synchronize with the current trace record.  In a live session it does.  Will open bug.
  • 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
The error decorator is shown in the editor if a tracepoint cannot be set, but it is not show in the Disassembly view.  Will open bug.
  • 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

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

Large array partitions

  • create an array with over 10000 elements
  • verify in both the variables and expressions view that the array shows partitions of 10000 elements containing partitions of 100 elements.

Edit Breakpoint on Create

  • Hit ctrl while double-clicking to create a breakpoint in the editor
  • verify the properties page for the bp opens before the breakpoint gets created
  • disable the bp in the properties dialog and close the dialog
  • verify the bp gets created but is disabled from the very creation
  • hold shift and double-click on the disabled bp just created
  • verify the breakpoint becomes enabled
  • hold shift and double-click on the same bp
  • verify bp gets enabled again
  • hold ctrl and double-click on the same bp
  • verify bp properties dialog opens

Show only suspended threads in Debug view

  • Enable preference to only show suspended threads
  • In a multi-threaded program verify that resuming a thread will make it disappear
  • Set a breakpoint in a running thread and verify that the thread eventually gets suspended and appears in the DV

Back to the top