Qt Creator ManualTests DebuggerCdb: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Clarify what the comments in simple.pro are for)
 
(28 intermediate revisions by 7 users not shown)
Line 1: Line 1:
=Qt Creator Manual Tests: Debugger <span class="caps">MSVC</span>/cdb=
[[Category:Tools::QtCreator::QualityAssurance]]


tests/manual/debugger/simple/simple.pro provides the needed code
For the following tests, you will need to build projects on Qt using MSVC and debug them using cdb. You can get a suitable build of Qt from the official [https://download.qt.io/official_releases/online_installers/ Online Installer].


{| class="infotable line"
{| class="wikitable"
|- style="background: #009900"
|+ Tests using ''tests/manual/debugger/simple/simple.pro'' from Qt Creator's source repository
! Test
! Test
! Result
! Result
! Annotation
! Annotation
|+
| Create new project. Can you build, run and debug it?
| automated
|
|-
|-
| Create new project. Can you build, run and debug it?
| Set breakpoint, press F5 to build and run debugger, verify that program stops at a breakpoint that you set:
| automated
* in main function before program is started
|
|-
|
Set breakpoint, press F5 to build and run debugger, verify that program stops at breakpoint:
 
* on main before program is started
* while the program is running
* while the program is running
* in dynamically loaded plugins, especially in constructors
* in dynamically loaded plugins, especially in constructors
* on a bit of code that was commented out. Make sure it is moved on debugger startup to the first line producing real code below that position and that it is hit there.
* on a bit of code that was commented out. Make sure it is moved on debugger startup to the first line producing real code below that position and that it is hit there.
|
|
|
|
|-
| Test breakpoint module resolution (see below)
|  
|  
|-
|-
| Test breakpoint module resolution (see below)
| "Step into" a couple of times. Can you step into Qt source code (*.cpp file under QTDIR. You might need to configure source paths mapping under "Edit" -> "Preferences…" -> "Debugger" -> "General" -> "Add Qt sources...")?
|
|  
|
|  
|-
|-
| “Step into” a couple of times. Can you step into Qt source code ('''*.cpp''' file under <span class="caps">QTDIR</span>)?
| Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure?  
|
| automated
|
|  
|-
|-
| Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure?
| Step through some (not all) test* functions and check whether the displayed data looks correct
|
|  
|
| The code contains comments with the expected displayed data. These are meant for semi-automatic runs and might differ from what you see. Use your own judgement what's correct and what's not.
|-
|-
| Stop at a breakpoint with one initialized QString, std::string and char[]. Can you edit their contents in “Locals and Expressions” view? Will the program continue with these changed values?
| Comment out the return statement inside the following functions one by one. Check whether you'll end up with a proper stack trace & locals display.
|
* testNullPointerDeref()
|
* testNullReference()
* testEndlessLoop(); (break manually)
* testEndlessRecursion();
* testUncaughtException();
|  
|  
|-
|-
| Step through some test* functions and check whether the displayed data looks sane
| Test a breakpoint in a QThread:
# Uncomment the call to qthread::testQThread()
# Place a breakpoint in qthread::Thread::run()
# Run this in the debugger
# Make sure that:
#* the breakpoint receives the right number of hits
#* "Locals and Expressions" and "Stack" views show reasonable data, including the object names of the threads
|
|
|
|
|-
|-
| Switch on temporarily 'Operate by Instruction' (small icon above the stack trace) and check whether you see disassembler output and can step by instruction
|
|
Remove the comment from the following lines one by one. Check whether you’ll end up with a proper stack trace &amp; locals display.
|}


* //*(int *)0 = 0;
{| class="wikitable"
* //testEndlessLoop(); (break manually)
|+ Tests using ''tests/manual/debugger/cli-io/cli-io.pro'' from Qt Creator's source repository
* //testEndlessRecursion();
! Test
|
! Result
|
! Annotation
|-
|+
| Switch on temporarily ‘Operate by Instruction’ and check whether you see disassembler output and can step by instruction
| Check I/O (qDebug, std::cout, std::cerr), on Win for both Debug and Release. Please read the below note!  
|
|  
|
|  
|-
| Check I/O (qDebug, std::cout, std::cerr), on Win for both Debug and Release. Please read the below note!
|
|
|-
|-
| Check “Run in Terminal”. Use Terminal for input.
| Check "Run in Terminal". Use Terminal for input.  
|
|  
|
|  
|-
|-
| Check nothing bad happens on a simple int main() {} program with no breakpoints set
| Check nothing bad happens on a simple int main() {} program with no breakpoints set  
| automated
| automated
|
|
|}
{| class="wikitable"
|+ Tests using ''tests/manual/debugger/gui/gui.pro'' from Qt Creator's source repository
! Test
! Result
! Annotation
|+
| Check registering for post-mortem debugging:
# Go to "Edit" -> "Preferences…" -> "Debugger" -> "General".
# Toggle "Use Qt Creator for post-mortem debugging"
# Click "OK"
# Go to "Edit" -> "Preferences…" -> "Debugger"-> "General" again.
# Verify that the check box "Use Qt Creator for post-mortem debugging" reflects the changes you made in step 2.
|
|
|-
|-
|
| Attach to a crashed process  
Check registering for post-mortem debugging:
|  
 
|  
# Go to “Tools” -&gt; “Options…” -&gt; “Debugger” -&gt; “General”.
# Toggle “Use Qt Creator for post-mortem debugging”
# Click “OK”
# Go to “Tools” -&gt; “Options…” -&gt; “Debugger” -&gt; “General” again.
# Verify that the check box “Use Qt Creator for post-mortem debugging” reflects the changes you made in step 2.
|
|
|-
| Attach to a crashed process
|
|
|-
|-
| Attach to a running process
|
|
|
# Start the project from outside Creator, e.g. from the command line.
# Attach Creator to the running process.<br/>Verify that you see a stack trace, variable values and code markers just as if you had run the application in the debugger from the beginning. You should also be able to pause/continue the execution.
|
|
|-
|-
|
| Test unusual situations: Kill X 'externally' while debugging (both in a 'running' and 'stopped' state), where X is
Test unusual situations: Kill X ‘externally’ while debugging (both in a ‘running’ and ‘stopped’ state), where X is
 
* the debugged program
* the debugged program
* cdb
* cdb  
|
|  
|
|  
|}
|}


==Breakpoint module resolution==
== Breakpoint module resolution ==
 
* Set a new breakpoint in application code (say ‘testapp’). Hover over breakpoint window, verify that ‘Module’ is empty in tooltip (enable tooltips in breakpoints window)
* Start the application, make it stop at breakpoint
* Finish debugging, restart debugger. Should be faster now
* Display tooltip of breakpoint again. Module should now be something ‘testapp’.
 
==stderr/stdout handling on Windows==


* An application needs to be built with ‘console’ for stderr/stdout to appear (use Creators “Run in terminal” setting)
* Set a new breakpoint in application code (say 'testapp').
* Creator itself is built with ‘console’ in debug mode only.
* Right-click into the breakpoint view and make sure that "Use Tooltips (...)" is checked.
* qDebug() prints to stderr for ‘console’ apps, else to the Windows debugger log, which can be shown with the DbgView utility
* Hover over breakpoint view, verify that 'Module' is empty in tooltip.
* <span class="caps">CDB</span> will catch only qDebug() when app is built without ‘console’, rest goes to app console as with normal Windows app.
* Start the application, make it stop at breakpoint.
* Finish debugging, restart debugger. Should be faster now.
* Display tooltip of breakpoint again. Module should now be something 'testapp'.


===Categories:===
== stderr/stdout handling on Windows ==


* [[:Category:Tools|Tools]]
* An application needs to be built with 'console' for stderr/stdout to appear (use Creator's "Run in terminal" setting)
** [[:Category:Tools::QtCreator|QtCreator]]
* Creator itself is built with 'console' in debug mode only.
* [[:Category:Tools::QtCreator::QualityAssurance|QualityAssurance]]
* qDebug() prints to stderr for 'console' apps, else to the Windows debugger log, which can be shown with the DbgView utility
* CDB will catch only qDebug() when app is built without ‘console’, rest goes to app console as with normal Windows app

Latest revision as of 10:47, 30 June 2023


For the following tests, you will need to build projects on Qt using MSVC and debug them using cdb. You can get a suitable build of Qt from the official Online Installer.

Tests using tests/manual/debugger/simple/simple.pro from Qt Creator's source repository
Test Result Annotation
Create new project. Can you build, run and debug it? automated
Set breakpoint, press F5 to build and run debugger, verify that program stops at a breakpoint that you set:
  • in main function before program is started
  • while the program is running
  • in dynamically loaded plugins, especially in constructors
  • on a bit of code that was commented out. Make sure it is moved on debugger startup to the first line producing real code below that position and that it is hit there.
Test breakpoint module resolution (see below)
"Step into" a couple of times. Can you step into Qt source code (*.cpp file under QTDIR. You might need to configure source paths mapping under "Edit" -> "Preferences…" -> "Debugger" -> "General" -> "Add Qt sources...")?
Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure? automated
Step through some (not all) test* functions and check whether the displayed data looks correct The code contains comments with the expected displayed data. These are meant for semi-automatic runs and might differ from what you see. Use your own judgement what's correct and what's not.
Comment out the return statement inside the following functions one by one. Check whether you'll end up with a proper stack trace & locals display.
  • testNullPointerDeref()
  • testNullReference()
  • testEndlessLoop(); (break manually)
  • testEndlessRecursion();
  • testUncaughtException();
Test a breakpoint in a QThread:
  1. Uncomment the call to qthread::testQThread()
  2. Place a breakpoint in qthread::Thread::run()
  3. Run this in the debugger
  4. Make sure that:
    • the breakpoint receives the right number of hits
    • "Locals and Expressions" and "Stack" views show reasonable data, including the object names of the threads
Switch on temporarily 'Operate by Instruction' (small icon above the stack trace) and check whether you see disassembler output and can step by instruction
Tests using tests/manual/debugger/cli-io/cli-io.pro from Qt Creator's source repository
Test Result Annotation
Check I/O (qDebug, std::cout, std::cerr), on Win for both Debug and Release. Please read the below note!
Check "Run in Terminal". Use Terminal for input.
Check nothing bad happens on a simple int main() {} program with no breakpoints set automated
Tests using tests/manual/debugger/gui/gui.pro from Qt Creator's source repository
Test Result Annotation
Check registering for post-mortem debugging:
  1. Go to "Edit" -> "Preferences…" -> "Debugger" -> "General".
  2. Toggle "Use Qt Creator for post-mortem debugging"
  3. Click "OK"
  4. Go to "Edit" -> "Preferences…" -> "Debugger"-> "General" again.
  5. Verify that the check box "Use Qt Creator for post-mortem debugging" reflects the changes you made in step 2.
Attach to a crashed process
  1. Start the project from outside Creator, e.g. from the command line.
  2. Attach Creator to the running process.
    Verify that you see a stack trace, variable values and code markers just as if you had run the application in the debugger from the beginning. You should also be able to pause/continue the execution.
Test unusual situations: Kill X 'externally' while debugging (both in a 'running' and 'stopped' state), where X is
  • the debugged program
  • cdb

Breakpoint module resolution

  • Set a new breakpoint in application code (say 'testapp').
  • Right-click into the breakpoint view and make sure that "Use Tooltips (...)" is checked.
  • Hover over breakpoint view, verify that 'Module' is empty in tooltip.
  • Start the application, make it stop at breakpoint.
  • Finish debugging, restart debugger. Should be faster now.
  • Display tooltip of breakpoint again. Module should now be something 'testapp'.

stderr/stdout handling on Windows

  • An application needs to be built with 'console' for stderr/stdout to appear (use Creator's "Run in terminal" setting)
  • Creator itself is built with 'console' in debug mode only.
  • qDebug() prints to stderr for 'console' apps, else to the Windows debugger log, which can be shown with the DbgView utility
  • CDB will catch only qDebug() when app is built without ‘console’, rest goes to app console as with normal Windows app
Retrieved from "https://wiki.qt.io/index.php?title=Qt_Creator_ManualTests_DebuggerCdb&oldid=40463"