Difference between revisions of "Hacking:Debug/Test"

From GIMP Developer Wiki
Jump to: navigation, search
m (move Dynamic analysis tools: to 'Testing for memory errors')
(Refer to devel-docs)
Line 24: Line 24:
 
== Using a debugger on plugins  ==
 
== Using a debugger on plugins  ==
  
Plugins run as separate processes.  Thus they won't appear in the gdb session for the main Gimp process. 
+
Plugins run as separate processes.   
You can invoke a plugin using the Gimp GUI ( say Filters>MyPlugin ).
+
Thus they won't appear in a gdb session for the main Gimp process.
While it is paused waiting for user input,
+
start another gdb session and "attach" gdb to the running filter process.
+
  
 +
You can still debug plugins.
 +
See the document [https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/debug-plug-ins.txt "Debugging Plugins"] in the GIMP repository.
 +
 +
The basic idea is a feature of gdb called "attaching to a running process."
 +
You start a gdb session and "attach" gdb to the PID of the running filter process.
 +
You start gdb giving it the filename of the plugin executable.
 +
The file is used to load symbols into the debugger.
 +
But you don't tell gdb to run the program file,
 +
instead you tell gdb to "attach" the already running program,
 +
wherever it is executing, i.e. wherever it's program counter is.
 +
 +
You can invoke a plugin using the Gimp GUI, say Filters>MyPlugin.
 +
While it is paused waiting for user input, you can attach gdb.
 +
 +
You can also tell GIMP that when it starts a particular plugin,
 +
the plugin should pause and print its PID, so that you can attach gdb.
 +
 +
When a plugin is not a C language program, but an interpreted language plugin, gdb will show interpreter code as well as plugin specific code.
 +
 +
Gdb works better when programs and libraries have been built with debug symbols and not stripped of debug symbols.
  
 
== Testing for memory errors ==
 
== Testing for memory errors ==

Revision as of 11:47, 17 May 2021

This describes tools and techniques for debugging and testing Gimp.


Tests in the build system

There are 'test' targets in the Gimp build systems (automake or meson):

  >make test  
  >ninja test

Using a debugger

You can use the gdb debugger by starting Gimp in the command line:

  >gdb gimp

Then:

  (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 a gdb session for the main Gimp process.

You can still debug plugins. See the document "Debugging Plugins" in the GIMP repository.

The basic idea is a feature of gdb called "attaching to a running process." You start a gdb session and "attach" gdb to the PID of the running filter process. You start gdb giving it the filename of the plugin executable. The file is used to load symbols into the debugger. But you don't tell gdb to run the program file, instead you tell gdb to "attach" the already running program, wherever it is executing, i.e. wherever it's program counter is.

You can invoke a plugin using the Gimp GUI, say Filters>MyPlugin. While it is paused waiting for user input, you can attach gdb.

You can also tell GIMP that when it starts a particular plugin, the plugin should pause and print its PID, so that you can attach gdb.

When a plugin is not a C language program, but an interpreted language plugin, gdb will show interpreter code as well as plugin specific code.

Gdb works better when programs and libraries have been built with debug symbols and not stripped of debug symbols.

Testing for memory errors

Tools for testing for memory errors:

  - Valgrind
  - AddressSanitizer

A short tutorial

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.


Using Valgrind

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.

Performance logs

Gimp's own document about performance logging

Fuzzing

Wiki article on fuzzing

A tutorial for fuzzing Gimp plugins

Homepage for zzuf fuzzer Install package 'zzuf'

   zzuf gimp

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:

   gimp --verbose

Reading a stack trace

TODO

Best if you build debug version:

--enable-debug