Qt Creator ManualTests DebuggerGdb: Difference between revisions
Jump to navigation
Jump to search
(Fix root tests) |
(Improve test for attaching) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
[[Category:Tools::QtCreator::QualityAssurance]] | [[Category:Tools::QtCreator::QualityAssurance]] | ||
For the following tests, you will need to build projects on Qt using gcc/MinGW. You can get such a build of Qt from the official [https://download.qt.io/official_releases/online_installers/ Online Installer]. | For the following tests, you will need to build projects on Qt using gcc/MinGW and debug them using gdb. You can get such a build of Qt from the official [https://download.qt.io/official_releases/online_installers/ Online Installer]. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 26: | Line 26: | ||
| | | | ||
|+ | |+ | ||
| Step through some (not all) test* functions and check whether the displayed data looks | | Step through some (not all) test* functions and check whether the displayed data looks correct | ||
| | | | ||
| The code contains comments with the expected displayed data. These are meant for semi-automatic runs and might differ from what you see. Use your own judgement what's correct and what's not. | |||
|+ | |+ | ||
| 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. | | 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. | ||
Line 86: | Line 86: | ||
|+ | |+ | ||
| | | | ||
When testing on Linux or Mac: | |||
# Run the project outside Creator. | # Run the project outside Creator. | ||
# Click the button "Crash".<br/>It should write a core file to the working directory. Depending on the operating system, you might have to set "ulimit | # Click the button "Crash".<br/>It should write a core file to the working directory. Depending on the operating system, you might have to set "ulimit -c unlimited" and/or disable OS-specific crash-reporting mechanisms, e.g. on [https://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-the-current-directory/ Ubuntu]. | ||
# Attach Creator to the core file.<br/>Verify that you see a stack trace, variable values and code markers just as if you had run the application in the debugger from the beginning. | # Attach Creator to the core file.<br/>Verify that you see a stack trace, variable values and code markers just as if you had run the application in the debugger from the beginning. | ||
| | | | ||
Line 94: | Line 95: | ||
| | | | ||
# Start the project from outside Creator, e.g. from the command line. | # Start the project from outside Creator, e.g. from the command line. | ||
# Attach Creator to the running process.<br/>Verify that you see a stack trace, variable values and code markers just as if you had run the application in the debugger from the beginning. You should also be able to pause/continue the execution. | # Attach Creator to the running process.<br/>If it doesn't work at first, Creator should show an error message why not. Make sure that this message is helpful and following its instruction will make attaching work.<br/>Verify that you see a stack trace, variable values and code markers just as if you had run the application in the debugger from the beginning. You should also be able to pause/continue the execution. | ||
| | | | ||
| | | | ||
Line 107: | Line 108: | ||
|+ | |+ | ||
| Try remote debugging: start a gdbserver using e.g. | | Try remote debugging: start a gdbserver using e.g. | ||
<code>gdbserver localhost:1234 ./ | <code>gdbserver localhost:1234 ./manual_test_debugger_gui</code> | ||
on a Linux machine and connect to it | |||
| | | | ||
|} | |} | ||
Line 143: | Line 144: | ||
| | | | ||
Debug the project with checking "Run as root user" on the run settings page. | Debug the project with checking "Run as root user" on the run settings page. | ||
# Verify application and debugger are starting correctly. | # Verify application and debugger are starting correctly.<br/>gdb running as "root" user is acceptable. | ||
# Use the OS' means to verify that the application is actually running for user "root". | # Use the OS' means to verify that the application is actually running for user "root". | ||
# Verify you can interrupt the application and hit a breakpoint. Check some locals whether they contain sane data. | # Verify you can interrupt the application and hit a breakpoint. Check some locals whether they contain sane data. |
Latest revision as of 10:32, 20 March 2024
For the following tests, you will need to build projects on Qt using gcc/MinGW and debug them using gdb. You can get such a build of Qt from the official Online Installer.
Test | Result | Annotation |
---|---|---|
Set breakpoint, press F5 to build and run debugger, verify that program stops at a breakpoint that you set:
|
||
"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 "Edit" -> "Preferences..." -> "Debugger" -> "General" -> "Add Qt sources...")?
(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? | automated | |
Step through some (not all) test* functions and check whether the displayed data looks correct | The code contains comments with the expected displayed data. These are meant for semi-automatic runs and might differ from what you see. Use your own judgement what's correct and what's not. | |
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.
|
||
Test a breakpoint in a QThread:
|
||
Switch on temporarily 'Operate by Instruction' (small icon above the stack trace) and check whether you see disassembler output and can step by instruction |
Test | Result | Annotation |
---|---|---|
Check I/O (qDebug, std::cout, std::cerr), on Win for both Debug and Release. | stderr/stdout handling on Windows:
|
|
Check "Run in Terminal". Use Terminal for input. (Debbuging might not work on Ubuntu) | ||
Create new project. Can you build, run and debug it? | automated | |
Check nothing bad happens on a simple int main() {} program with no breakpoints set | automated |
Test | Result | Annotation |
---|---|---|
When testing on Linux or Mac:
|
||
|
||
Test unusual situations: Kill the running debugged program 'externally' with a signal that is neither SIGSTOP nor SIGKILL. Qt Creator should end up showing a backtrace. | ||
Kill the stopped debugged program 'externally'. Nothing should happen immediately, on next continue or step Qt Creator should end up showing a backtrace. | ||
Try remote debugging: start a gdbserver using e.g.
gdbserver localhost:1234 ./manual_test_debugger_gui
on a Linux machine and connect to it |
Test | Result | Annotation |
---|---|---|
Run the project without checking "Run as root user" on the run settings page.
|
||
Debug the project without checking "Run as root user" on the run settings page.
|
||
Run the project with checking "Run as root user" on the run settings page.
|
||
Debug the project with checking "Run as root user" on the run settings page.
|
||
Is entering invalid credentials handled correctly? |