Debugging with GDB¶
A debugger can be used to inspect the state of an application in the event of a crash.
Compile Debug Build¶
How to make a debug build depends on the build system used:
- For Linux/macOS set:
CMAKE_BUILD_TYPE=Debug
inCMakeCache.txt
- For Visual Studio, set the Release Configuration to Debug
Run GDB¶
Start GDB by changing the working directory to the location of your new debug build and typing one of the following, depending on the platform:
Then to start Blender, type:
Now make Blender crash. Blender will freeze, so switch to the GDB prompt. Get a backtrace by typing:
A more complete backtrace can be printed using:
For more information, see this guide: How to Get a Backtrace.
Run Immediately¶
Blender can be made to run immediately:
Run With Environment Variables Set¶
Blender can be run with environment variables using env
.
These options disable some ASAN checks can interfere with debugging:
gdb ./blender --ex=run --args env ASAN_OPTIONS=check_initialization_order=0:leak_check_at_exit=0 ./blender
Pretty Printing¶
By default, GDB does not know how to print many Blender core types such as blender::Vector
in a
good way. The Blender source code contains a bunch of pretty printers that can be registered in GDB
which simplify debugging.
To register those pretty printers add the following line to a ~/.gdbinit
file. Everything in this
file is run by GDB when it is started. Make to use the correct file path if the source code is
elsewhere.
The following steps can check if the registration was successfull.
- Start
gdb
. - Run
info pretty-printer
in GDB and check forblender-pretty-printers
.
This also registers other utilities for GDB like frame filters. See blender_gdb_extension.py
for
details.
As an example, this is how a blender::Vector<int>
with three elements is printed with and without
pretty printers.