| 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 Tools -> Options -> Debugger -> Add Qt sources...)?
|
|
|
| Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure?
|
automated
|
|
| Stop at a breakpoint with one initialized QString, std::string and int. Can you edit their contents in "Locals and Expressions" view? Will the program continue with these changed values?
|
|
|
| Step through some (not all) test* functions and check whether the displayed data looks sane
|
|
|
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:
- 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
|
|