Difference between revisions of "Hacking:Debug/Test"

From GIMP Developer Wiki
Jump to: navigation, search
(Created page with "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):...")
(No difference)

Revision as of 12:54, 13 July 2020

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.

Performance logs

See [1]

Fuzzing

See [2]

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

Dynamic analysis tools

You might try:

  • valgrind
  • address sanitizer

Some snippets:

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

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