CDT/Obsolete/8.1 RC3 Testing

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