This section lists some typical problems that you might encounter while debugging and solutions to them.
Some anti-virus applications do not allow debuggers to retrieve data. For example, on Windows, launching the debugger might fail with the following message if the Avira AntiVir is installed on the development PC: The inferior stopped because it received a signal from the operating system. Signal name:? signal meaning: Unknown signal.
Some versions of Avira AntiVir Desktop-Products contain known issues in various development environments, including Qt Creator. To fix the problem, Avira instructs you to update to version avipbb.sys 10.0.22.22. For more information, see Restricted Usability of IDE/Debuggers since 2010-12-08.
You might have created a release build that does not contain debug information. A GNU Compiler Collection (GCC) debug build has the -g option on the compiler command line. Check that this option is present in the Compile Output pane. If it is not, adjust your build settings in the Projects mode.
If the debugger does not work properly, try the following:
When you use the Locals and Expressions view to inspect a pointer variable and expand the variable tree item, another tree item level is displayed. To directly display the members of the pointer variable, select Dereference Pointers Automatically in the context menu in the Locals and Expressions view.
By default, structure members are displayed in alphabetic order. To inspect the real layout in memory, deselect Sort Members of Classes and Structs Alphabetically in the context menu in the Locals and Expressions view.
The part of the slowness that is related to the loading of debug information is hard to avoid. Another part stems from maintaining breakpoints inside the debugger (under some circumstances all breakpoints need to be inserted and removed again for each step) and the evaluation of expressions after each step. We recommend that you minimize the number of breakpoints and watched expressions.
The message is created by the debugging helpers. Qt Creator posts an expression to the GDB command line to invoke the debugging helpers. The expression includes the address of the object to examine. This address might be modified by GDB before the helper function is called. It is unclear why and when this happens, but if it happens, the debugging helpers operate on wrong data and come to wrong conclusions. Most likely, they find garbage and declare the variable to be <not in scope>.
You must use a workaround to use the DYLD_IMAGE_SUFFIX option in the Projects tab on Mac OS X Snow Leopard. For more information on the issue, see DYLD_IMAGE_SUFFIX causing havoc on Mac OS X Snow Leopard.
To use the option, enter the following commands in the Terminal application:
sudo mv /usr/lib/libSystem.B_debug.dylib /usr/lib/libSystem.B_debug.dylib.backup sudo cp /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B_debug.dylib.backup
GDB uses ptrace to attach to running processes. Some Linux distributions do not allow this, which stops all attempts to either directly attach to an existing process or use the Run in terminal option in Qt Creator.
The reasons for this are described in KernelHardening.
However, the usefulness of this security measure seems dubious, because this feature can be easily disabled. With root permissions, you can disable the feature temporarily by writing 0 into /proc/sys/kernel/yama/ptrace_scope or permanently by changing the value in /etc/sysctl.d/10-ptrace.conf. Even if you do not have elevated permissions, you can disable the feature later by adding a library that calls prctl(0x59616d61, getppid(), 0, 0, 0);, such as the one in $QTCREATORDIR/lib/libptracepreload.so to the LD_PRELOAD environment.