Hacking:Debug/Test

From GIMP Developer Wiki
Jump to: navigation, search

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 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.


Address sanitize

A tutorial


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

Dynamic analysis tools

You might try:

  • valgrind install package 'valgrind'
  • address sanitizer

Some snippets:

   >valgrind --track-origins=yes gimp
   setenv LD_PRELOAD=libasan.so.2 gimp-2.9

You can configure a meson build with -Db_sanitize=address.