Difference between revisions of "Hacking:Debug/Test"
(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):...") |
m |
||
| Line 28: | Line 28: | ||
While it is paused waiting for user input, | While it is paused waiting for user input, | ||
start another gdb session and "attach" gdb to the running filter process. | start another gdb session and "attach" gdb to the running filter process. | ||
| + | |||
| + | |||
| + | == Address sanitize == | ||
| + | |||
| + | [https://lemire.me/blog/2016/04/20/no-more-leaks-with-sanitize-flags-in-gcc-and-clang/ A tutorial] | ||
| + | |||
== Performance logs == | == Performance logs == | ||
| − | + | [https://gitlab.gnome.org/GNOME/gimp/blob/master/devel-docs/performance-logs/performance-logs.md Gimp's own document about performance logging] | |
== Fuzzing == | == Fuzzing == | ||
| − | + | [https://en.wikipedia.org/wiki/Fuzzing Wiki article on fuzzing] | |
| + | |||
| + | [https://flimp.fuzzing-project.org/tutorial-fuzzing-gimp.html A tutorial for fuzzing Gimp plugins] | ||
| + | |||
| + | [https://caca.zoy.org/wiki/zzuf 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 == | == Running Gimp in verbose mode == | ||
| Line 46: | Line 61: | ||
TODO | TODO | ||
| + | |||
| + | Best if you build debug version: | ||
| + | |||
| + | --enable-debug | ||
== Dynamic analysis tools == | == Dynamic analysis tools == | ||
| Line 51: | Line 70: | ||
You might try: | You might try: | ||
| − | * valgrind | + | * valgrind install package 'valgrind' |
| + | |||
* address sanitizer | * address sanitizer | ||
Some snippets: | Some snippets: | ||
| − | valgrind --track-origins=yes | + | >valgrind --track-origins=yes gimp |
setenv LD_PRELOAD=libasan.so.2 gimp-2.9 | setenv LD_PRELOAD=libasan.so.2 gimp-2.9 | ||
You can configure a meson build with -Db_sanitize=address. | You can configure a meson build with -Db_sanitize=address. | ||
Revision as of 15:54, 15 July 2020
This describes tools and techniques for debugging and testing Gimp.
Contents
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
Performance logs
Gimp's own document about performance logging
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.
