Qt Creator ManualTests DebuggerCdb: Difference between revisions
Jump to navigation
Jump to search
(Improve breakpoint test) |
(better explanation for module resolution) |
||
Line 98: | Line 98: | ||
== Breakpoint module resolution == | == Breakpoint module resolution == | ||
* Set a new breakpoint in application code (say 'testapp'). Hover over breakpoint | * Set a new breakpoint in application code (say 'testapp'). | ||
* Start the application, make it stop at breakpoint | * Right-click into the breakpoint view and make sure that "Use Tooltips (...)" is checked. | ||
* Finish debugging, restart debugger. Should be faster now | * 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'. | * Display tooltip of breakpoint again. Module should now be something 'testapp'. | ||
Revision as of 17:27, 15 March 2016
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 a breakpoint that you set:
|
||
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 | ||
Comment out the return statement before the following code lines or inside the respective functions one by one. Check whether you'll end up with a proper stack trace & locals display.
|
||
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:
|
||
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
|
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