File: debug-plug-ins.txt

package info (click to toggle)
gimp 2.2.6-1sarge4
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 97,088 kB
  • ctags: 43,756
  • sloc: ansic: 525,782; xml: 36,543; lisp: 9,851; sh: 9,007; makefile: 7,974; python: 2,622; perl: 2,589; yacc: 520; lex: 334
file content (82 lines) | stat: -rw-r--r-- 2,691 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
Debugging Plug-ins
==================

Eeek! The plug-in you're working on has a bug in it! And the fix isn't
completely obvious, so you want to use debugger to see what is going on.
But hmm, how does one start a plug-in under a debugger if GIMP is the one
who is starting the plug-in...

To address this issue, libgimp has some hooks controlled by the
GIMP_PLUGIN_DEBUG environment variable. The idea is that you can attach
a debugger to the pid of the plug-in you want to debug. The format is as
follows:


GIMP_PLUGIN_DEBUG=name<,options>

"name" refers to the name of the plug-in binary that you wish to debug.

"options" is one or more of the following options, separated by :'s

    run:            suspend the plug-in when its run_proc is called.
    query:          suspend the plug-in when its query_proc is called.
    init:           suspend the plug-in when its init_proc is called.
    pid:            just print the pid of the plug-in on run_proc.
    fatal-warnings: emulate passing --g-fatal-warnings on the command line.
    fw:             shorthand for above.
    on:             shorthand for run:fatal-warnings. This is also the default
                    in the absence of an options string.

Examples:

GIMP_PLUGIN_DEBUG=blur

    When the blur plug-in is called to perform an action, it is suspended
    and the following is printed to the console:

    (blur:9000): LibGimp-DEBUG: Waiting for debugger...

    9000 is the pid of the new plug-in process. You can start your debugger,
    attach to it, set breakpoints/watches/etc. and continue from there.

GIMP_PLUGIN_DEBUG=blur,on

    Same effect as above.

GIMP_PLUGIN_DEBUG=blur,run:fatal-warnings

    Same effect as above.

GIMP_PLUGIN_DEBUG=blur,pid

    Prints:

    (blur:9000): LibGimp-DEBUG: Here I am!

    This simply prints the pid but doesn't halt the plug-in. It is simply
    convenience, since if your plug-in has a GUI, the GUI can start up
    and you can attach to it there while it is waiting for user input.

GIMP_PLUGIN_DEBUG=blur,query

    Same effect as if you did run, but instead suspends when the plug-in
    is queried on GIMP startup.

GIMP_PLUGIN_DEBUG=blur,init

    Same as above, but in the init phase of startup.


Hmm, but what about memory debuggers such as valgrind or purify? For those
you can set the following:

GIMP_PLUGIN_DEBUG_WRAP=name<,options>

    This is similar to GIMP_PLUGIN_DEBUG. Only "query", "init", and "run"
    are valid, and "on" defaults to simply "run"

GIMP_PLUGIN_DEBUG_WRAPPER=debugger

    debugger refers to the debugger program, such as valgrind. You can
    put command line options here too, they will be parsed like they do
    in the shell.