Re: Debugging Gimp plugins

Re: Debugging Gimp plugins

[lduperval]

On  8 Feb, Keith Seitz wrote:
> lduperval@sprint.ca wrote:
>> 
>> Hi,
>> 
>> If anyone has experience successfully debugging gimp plugins with
>> insight, please drop me a line. I can't figure out the proper way to do
>> it yet.
>> 
>> L
> 
> I don't know much about the Gimp (gasp!),

Hhhhhhhhhh!! Shame! Shame! :-)

> but I assume that it's plugins
> are just loadable modules (almost identical to shared libraries).
> 

I don't think so. I've looked at the source and it seems to be
socket-based. It looks like the plugin is a standalone program that
communicates with GIMP using sockets. But don't take my word for it.

So my situation is that I'm trying to write a Tcl-based extension (or at
least make an old one work with the new GIMP). It requires running a new
wish process. That wish process loads a dynamic module. And there are
some dependencies on shared libs also. I find it to be a debugging mess
but I thing it would be an even bigger mess for me to try to compile a
monolithic binary containing the Tcl, Tk, gtk, gdk, glib and my own libs
all in one.

> If so, I've found that the easiest way to debug them is to set
> breakpoints AFTER the module is loaded (i.e., after gdb knows about its
> symbols). For example, if there is a way to harmlessly load the module
> with the gimp, do that. Then interrupt the program and set your
> breakpoint(s) as normal.
> 
> If your module does something naughty before you can do this, you'll
> need to find out what function in Gimp loads the module and set a break
> there. After the module is loaded, its symbol table will be available to
> you.
> 
> The problem is that gdb doesn't know that modules even exist. If that
> wasn't bad enough, if you attempt to add symbols from the modules (via
> add-symbol-file), you'll need to know the starting address for the text
> of the the module (after it is loaded into memory, that is)! Yikes!
> 

Yikes is right. Someone on the gimp newsgroups suggested something
similar so I'll be trying it this week (provided I can get more than 10
minutes of work done). If it doesn't work, looks like I'll be going the
static compile route. Ugh!

Thanks for the suggestions.

L

Re: Debugging Gimp plugins

[James Ingham]

lduperval@sprint.ca,

I guess that I missed some of this discussion, so I don't know for
sure what is going on.  But if Gimp or Tcl is actively loading 
the module (rather than it getting pulled in automatically by the
loader) then either program is almost certainly doing this by calling
dlopen.  For instance, Tcl does this with the "load" command.

Try putting a break on dlopen, and then let 'er rip.  You can check
the "path" argument till it is your shared library, and when you get
to your module, you can just finish out of the dlopen code, and then
you will have real symbols.  Worth a try anyway.

Turns out that on most natives, gdb actually does something like this, 
breaking on the loader itself so that it can add the symbols when a
new library is loaded in.  What would be really useful is a gdb
command that says - when you load a library that matches this regexp,
break after the loader has done its job...  As far as I know, however, 
this does not exist at present.

Jim

 > On  8 Feb, Keith Seitz wrote:
 > > lduperval@sprint.ca wrote:
 > >> 
 > >> Hi,
 > >> 
 > >> If anyone has experience successfully debugging gimp plugins with
 > >> insight, please drop me a line. I can't figure out the proper way to do
 > >> it yet.
 > >> 
 > >> L
 > > 
 > > I don't know much about the Gimp (gasp!),
 > 
 > Hhhhhhhhhh!! Shame! Shame! :-)
 > 
 > > but I assume that it's plugins
 > > are just loadable modules (almost identical to shared libraries).
 > > 
 > 
 > I don't think so. I've looked at the source and it seems to be
 > socket-based. It looks like the plugin is a standalone program that
 > communicates with GIMP using sockets. But don't take my word for it.
 > 
 > So my situation is that I'm trying to write a Tcl-based extension (or at
 > least make an old one work with the new GIMP). It requires running a new
 > wish process. That wish process loads a dynamic module. And there are
 > some dependencies on shared libs also. I find it to be a debugging mess
 > but I thing it would be an even bigger mess for me to try to compile a
 > monolithic binary containing the Tcl, Tk, gtk, gdk, glib and my own libs
 > all in one.
 > 
 > > If so, I've found that the easiest way to debug them is to set
 > > breakpoints AFTER the module is loaded (i.e., after gdb knows about its
 > > symbols). For example, if there is a way to harmlessly load the module
 > > with the gimp, do that. Then interrupt the program and set your
 > > breakpoint(s) as normal.
 > > 
 > > If your module does something naughty before you can do this, you'll
 > > need to find out what function in Gimp loads the module and set a break
 > > there. After the module is loaded, its symbol table will be available to
 > > you.
 > > 
 > > The problem is that gdb doesn't know that modules even exist. If that
 > > wasn't bad enough, if you attempt to add symbols from the modules (via
 > > add-symbol-file), you'll need to know the starting address for the text
 > > of the the module (after it is loaded into memory, that is)! Yikes!
 > > 
 > 
 > Yikes is right. Someone on the gimp newsgroups suggested something
 > similar so I'll be trying it this week (provided I can get more than 10
 > minutes of work done). If it doesn't work, looks like I'll be going the
 > static compile route. Ugh!
 > 
 > Thanks for the suggestions.
 > 
 > L
 > 
 > 
 > 

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@redhat.com
Red Hat, Inc.                      

Debugging Gimp plugins

[lduperval]

Hi,

If anyone has experience successfully debugging gimp plugins with
insight, please drop me a line. I can't figure out the proper way to do
it yet.

L