Qt Creator ManualTests DebuggerGdb: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
=Qt Creator Manual Tests: Debugger g++/gdb=
[[Category:Tools::QtCreator::QualityAssurance]]
 
= Qt Creator Manual Tests: Debugger g++/gdb =


tests/manual/debugger/simple/simple.pro and tests/manual/debugger/cli-io/cli-io.pro provide the needed code
tests/manual/debugger/simple/simple.pro and tests/manual/debugger/cli-io/cli-io.pro provide the needed code


{| class="infotable line"
{background:#009900}. |''. Test |''. Result |_. Annotation |<br />| Create new project. Can you build, run and debug it? | automated, except on Mac | |<br />| Set breakpoint, press F5 to build and run debugger, verify that program stops at breakpoint:<br />* on main before program is started<br />* while the program is running<br />* in dynamically loaded plugins, especially in constructors<br />* 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. | | |<br />| &quot;Step into&amp;quot; a couple of times. Can you step into Qt source code ('''&amp;#42;.cpp''' file under QTDIR)?<br />(Mac: switch on 'Use Debug Versions of Frameworks' in run configuration. You need Qt sources.) | | |<br />| Test debugging helpers/python gdb: Do classes like QImage or std::string show beautiful information instead of the raw structure? | | |<br />| Step through some test* functions and check whether the displayed data looks sane | | |<br />| 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 &amp; locals display.<br />* '''<span class="* int">0 = a + b;<br /></span>''' testNullReferenceHelper(pp, qq);<br />* testEndlessLoop(); (break manually)<br />* testEndlessRecursion();<br />* testUncaughtException();| | |<br />| Switch on temporarily 'Operate by Instruction' and check whether you see disassembler output and can step by instruction | | |<br />| Check I/O (qDebug, std::cout, std::cerr), on Win for both Debug and Release. Please read the below note! | | |<br />| Check &quot;Run in Terminal&amp;quot;. Use Terminal for input. (Debbuging might not work on Ubuntu) | | |<br />| Check nothing bad happens on a simple int main() {} program with no breakpoints set | automated, except on Mac | |<br />| Linux/Mac: Attach to a core file &amp;#40;ulimit -c unlimited&amp;amp;#41; | | |<br />| Attach to a running process (might not work on Ubuntu) | | |<br />| Try remote debugging: start a gdbserver using e.g.<br /><code>gdbserver localhost:1234 ./fakevim<code><br />in creator/tests/manual/fakevim on a Linux machine and connect to it | | |<br />| Test unusual situations: Kill X 'externally' while debugging (both in a 'running' and 'stopped' state), where X is<br />* the debugged program<br />* gdb | | |
|- style="background: #009900"
! Test
! Result
! Annotation
|-
| Create new project. Can you build, run and debug it?
| automated, except on Mac
|
|-
|
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.
|
|
|-
| “Step into” a couple of times. Can you step into Qt source code ('''*.cpp''' file under <span class="caps">QTDIR</span>)?<br /> (Mac: switch on ‘Use Debug Versions of Frameworks’ in run configuration. You need Qt sources.)
|
|
|-
| Test debugging helpers/python gdb: Do classes like QImage or std::string show beautiful information instead of the raw structure?
|
|
|-
| 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 &amp; locals display.
 
* <nowiki>*(int *)0 = a + b;</nowiki>
* testNullReferenceHelper(pp, qq);
* testEndlessLoop(); (break manually)
* testEndlessRecursion();
* testUncaughtException();
|
|
|-
| 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. (Debbuging might not work on Ubuntu)
|
|
|-
| Check nothing bad happens on a simple int main() {} program with no breakpoints set
| automated, except on Mac
|
|-
| Linux/Mac: Attach to a core file (ulimit -c unlimited)
|
|
|-
| Attach to a running process (might not work on Ubuntu)
|
|
|-
| Try remote debugging: start a gdbserver using e.g.<br /> in creator/tests/manual/fakevim on a Linux machine and connect to it
|
|
|-
|
Test unusual situations: Kill X ‘externally’ while debugging (both in a ‘running’ and ‘stopped’ state), where X is
 
* the debugged program
* gdb
|
|
|}
 
==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


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


* [[:Category:Tools|Tools]]
* An application needs to be built with 'console' for stderr/stdout to appear (use Creators &quot;Run in terminal&amp;quot; setting)
** [[:Category:Tools::QtCreator|QtCreator]]
* Creator itself is built with 'console' in debug mode only.
* [[:Category:Tools::QtCreator::QualityAssurance|QualityAssurance]]

Revision as of 10:57, 24 February 2015


Qt Creator Manual Tests: Debugger g++/gdb

tests/manual/debugger/simple/simple.pro and tests/manual/debugger/cli-io/cli-io.pro provide the needed code

{background:#009900}. |. Test |. Result |_. Annotation |
| Create new project. Can you build, run and debug it? | automated, except on Mac | |
| 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. | | |
| "Step into&quot; a couple of times. Can you step into Qt source code (&#42;.cpp file under QTDIR)?
(Mac: switch on 'Use Debug Versions of Frameworks' in run configuration. You need Qt sources.) | | |
| Test debugging helpers/python gdb: Do classes like QImage or std::string show beautiful information instead of the raw structure? | | |
| 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.
* 0 = a + b;
 testNullReferenceHelper(pp, qq);
* testEndlessLoop(); (break manually)
* testEndlessRecursion();
* testUncaughtException();| | |
| 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&quot;. Use Terminal for input. (Debbuging might not work on Ubuntu) | | |
| Check nothing bad happens on a simple int main() {} program with no breakpoints set | automated, except on Mac | |
| Linux/Mac: Attach to a core file &#40;ulimit -c unlimited&amp;#41; | | |
| Attach to a running process (might not work on Ubuntu) | | |
| Try remote debugging: start a gdbserver using e.g.
gdbserver localhost:1234 ./fakevim
in creator/tests/manual/fakevim on a Linux machine and connect to it | | |
| Test unusual situations: Kill X 'externally' while debugging (both in a 'running' and 'stopped' state), where X is
* the debugged program
* gdb | | |

stderr/stdout handling on Windows

  • An application needs to be built with 'console' for stderr/stdout to appear (use Creators "Run in terminal&quot; setting)
  • Creator itself is built with 'console' in debug mode only.
Retrieved from "https://wiki.qt.io/index.php?title=Qt_Creator_ManualTests_DebuggerGdb&oldid=5065"