Qt Creator ManualTests DebuggerCdb: Difference between revisions
Jump to navigation
Jump to search
(Fix broken import, add headline, small update.) |
m (Insert missing apostrophe) |
||
Line 105: | Line 105: | ||
== stderr/stdout handling on Windows == | == stderr/stdout handling on Windows == | ||
* An application needs to be built with 'console' for stderr/stdout to appear (use | * 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. | * 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 | * 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 | * CDB will catch only qDebug() when app is built without ‘console’, rest goes to app console as with normal Windows app |
Revision as of 16:14, 20 July 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:
|
||
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'). 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 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