This describes tools and techniques for debugging and testing Gimp.
- 1 Tests in the build system
- 2 Using a debugger
- 3 Using a debugger on plugins
- 4 Testing for memory errors
- 5 Performance logs
- 6 Fuzzing
- 7 Running Gimp in verbose mode
- 8 Reading a stack trace
Tests in the build system
There are 'test' targets in the Gimp build systems (automake or meson):
Using a debugger
You can use the gdb debugger by starting Gimp in the command line:
(gdb) run (or set breakpoints etc.)
It is usually best to have a "debug" build of gimp, that has not been stripped of debug symbols (using the "strip" command.)
Using a debugger on plugins
Plugins run as separate processes. Thus they won't appear in the gdb session for the main Gimp process. You can invoke a plugin using the Gimp GUI ( say Filters>MyPlugin ). While it is paused waiting for user input, start another gdb session and "attach" gdb to the running filter process.
Testing for memory errors
Tools for testing for memory errors:
These tools are one kind of dynamic program analysis. They detect errors while Gimp is running.
These tools often produce spurious messages, and rarely find significant issues. To use them properly, you must have a deep understanding of a program's memory use, and you must spend much time interpreting messages.
Install the package: valgrind
Valgrind requires no recompilation of Gimp.
To run gimp inside valgrind:
>valgrind --track-origins=yes gimp
Using AddressSanitizer with automake build using gcc compiler
Install the package that includes the asan runtime library?
Rebuild gimp, define an environment variable to tell the gcc compiler to use address sanitizer:
CFLAGS="-fsanitize=address -fno-omit-frame-pointer" ./autogen.sh --disable-docs --enable-debug make -j4 make install
When you run gimp, tell the loader to load the asan runtime library first:
export LD_PRELOAD=$(gcc -print-file-name=libasan.so) /usr/local/bin/gimp-2.99
(Otherwise, when you run a plugin, it is not compiled with address sanitize, yet the Gimp libraries are, and AddressSanitizer complains that it wants to load its runtime library first, to catch all calls to malloc.)
Using AddressSanitizer with meson build using clang compiler
Install your distribution's packages that contain llvm tools [clang, lld]
Rebuild gimp, define environment variables to use clang compiler and llvm linker and use the shared kind of asan runtime library:
CC=clang CXX=clang++ CC_LD=/usr/bin/ld.lld CXX_LD=/usr/bin/ld.lld LDFLAGS=-shared-libasan meson _build \ --buildtype=debug \ ... -Db_sanitize=address
As of this writing, the meson build of gimp is experimental, not supported. As of this writing, the above fails to build.
Homepage for zzuf fuzzer Install package 'zzuf'
Although it usually stops early. TODO how to delay fuzzing til an image is loaded?
Running Gimp in verbose mode
You can make Gimp print more information about what it is doing, in a command line of a terminal:
Reading a stack trace
Best if you build debug version: