Qt Creator ManualTests DebuggerCdb: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Decode HTML entity numbers)
(Table)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
 


[[Category:Tools::QtCreator::QualityAssurance]]
[[Category:Tools::QtCreator::QualityAssurance]]


= Qt Creator Manual Tests: Debugger MSVC/cdb =


[toc align_right="yes" depth="2"]
 
 


tests/manual/debugger/simple/simple.pro provides the needed code
tests/manual/debugger/simple/simple.pro provides the needed code


{background:#009900}. |''. Test |''. Result |_. Annotation |
{| class="wikitable"
| Create new project. Can you build, run and debug it? | automated | |
! 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 breakpoint:
| Set breakpoint, press F5 to build and run debugger, verify that program stops at breakpoint:
* on main before program is started
* 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) | | |
|  
| "Step into" a couple of times. Can you step into Qt source code ('''*.cpp''' file under QTDIR)? | | |
|  
| Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure? | | |
|-
| 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? | | |
| Test breakpoint module resolution (see below)  
| Step through some test* functions and check whether the displayed data looks sane | | |
|  
|  
|-
| "Step into" a couple of times. Can you step into Qt source code ('''*.cpp''' file under QTDIR)?  
|  
|  
|-
| Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure?  
|  
|  
|-
| 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?  
|  
|  
|-
| Step through some test* functions and check whether the displayed data looks sane  
|  
|  
|-
| Remove the comment from the following lines one by one. Check whether you'll end up with a proper stack trace & locals display.
| Remove the comment from the following lines one by one. Check whether you'll end up with a proper stack trace & locals display.
* //*(int ''')0 = 0;
* //*(int ''')0 = 0;
''' //testEndlessLoop(); (break manually)
''' //testEndlessLoop(); (break manually)
* //testEndlessRecursion();| | |
* //testEndlessRecursion();
| 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 "Run in Terminal". Use Terminal for input. | | |
|-
| Check nothing bad happens on a simple int main() {} program with no breakpoints set | automated | |
| 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 "Run in Terminal". Use Terminal for input.  
|  
|  
|-
| Check nothing bad happens on a simple int main() {} program with no breakpoints set  
| automated  
|  
|-
| Check registering for post-mortem debugging:
| Check registering for post-mortem debugging:
# Go to "Tools" -> "Options…"-> "Debugger" -> "General".
# Go to "Tools" -> "Options…"-> "Debugger" -> "General".
Line 34: Line 74:
# Click "OK"
# Click "OK"
# Go to "Tools"-> "Options…" -> "Debugger"-> "General" again.
# Go to "Tools"-> "Options…" -> "Debugger"-> "General" again.
# Verify that the check box "Use Qt Creator for post-mortem debugging" reflects the changes you made in step 2. | | |
# 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 | | |
|  
|-
| Attach to a crashed process  
|  
|  
|-
| Attach to a running process  
|  
|  
|-
| 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 ==

Revision as of 07:49, 7 April 2015




tests/manual/debugger/simple/simple.pro provides the needed code

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 breakpoint:
  • on main 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)?
Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure?
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?
Step through some test* functions and check whether the displayed data looks sane
Remove the comment from the following lines one by one. Check whether you'll end up with a proper stack trace & locals display.
  • //*(int )0 = 0;

//testEndlessLoop(); (break manually)

  • //testEndlessRecursion();
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 "Run in Terminal". Use Terminal for input.
Check nothing bad happens on a simple int main() {} program with no breakpoints set automated
Check registering for post-mortem debugging:
  1. Go to "Tools" -> "Options…"-> "Debugger" -> "General".
  2. Toggle "Use Qt Creator for post-mortem debugging"
  3. Click "OK"
  4. Go to "Tools"-> "Options…" -> "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
Attach to a running process
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'). 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)
  • 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