home contents changes options help

by Robin Rowe

Q: Has anyone come up with a way to debug Linux plug-ins?

See below the remarks from Kai-Uwe.

Linux CinePaint still uses the forked plug-in architecture. In theory, you could stop in the debugger at fork() and attach to the created process. There is a function in GTK to help with this, and that some have encountered in CinePaint when it segfaults. Instead of dumping it would call up the GTK handler to ask if you want to halt or debug. I never found that to work as advertised, but didn't try too hard since tracing into forked plug-ins seems kind of goofy on principle. My plan is to thread Linux plug-ins much like we have in Windows. However, the gdb debugger has problems tracing into threaded plug-ins.

Last year when I was working on a project with threaded plug-ins (not forked like in Linux CinePaint) I encountered gdb problems. Both tools were being worked on. Reportedly, g++ was not emitting the right debug information for gdb. It was suggested that installing the latest gdb and g++ from CVS might correct the problem I was seeing, and I would be able to trace into plug-ins. That approach was too bleeding edge (for a project I was working on inside a studio), and I decided to wait for the tools to settle down. I did the debugging the hard way with printf.

I normally do debugging in VC++ where plug-ins can be stepped into with no problem. That our Windows build is currently broken, and that I've been too busy to work on fixing it, is a serious problem for us on all our platforms. Without the Windows debugging tools I can't debug hard CinePaint bugs effectively. As soon as I get release 0.19 done I will go back to making repairs on our Windows build.

Let me know if anyone researches the latest Linux g++/gdb tools, if the problems there are now resolved.

Yes, below the path is added by Kai-Uwe for debugging with gdb/DDD.

The CP_DBG_PLUGINS and CP_DBG_PLUG_IN variable handle this for Gtk CinePaint in 0.21-2.

CP_DBG_PLUG_INS is a global wrapper (old 0.21-2: stopper), while CP_DBG_PLUG_IN is sensible to a plug-in name. Use it like:

$ export CP_DBG_PLUG_IN=py

to debug each python plug-in. On the command line you will see something like: $ plugin_main.c:146 plugin_main() running /blur in GDB: attach 6687 For instance you can now the requested plug-in into gdb or DDD. $ gdb /somewhere/cinepaint-0.22-0/plug-ins/blur/.libs/blur Prepared a breakpoint in the plug-in code, possibly in run(), gdb will later stop there. Put then the attach line from above into the gdb command promt. $ attach 6687 Gdb should stop somewhere in the library code and you need to break a while instruction. Simply set the dbg variable to 0. $ set variable dbg = 0 Let gdb run into you previously set breakpoint. $ cont Continue as usual with debugging.

$ export CP_DBG_PLUGINS=valgrind

will call valgrind with usual plug-in command line after it. Note: valgrind can be a wrapping script to allow more arguments to valgrind such as --trace-children=yes . CP_DBG_PLUGINS is very handy to debug just one single plug-in. The whole CinePaint session is very slow under valgrind.

Kai-Uwe updated: 08:29:11, 08.04.2007


... -- Wed, 10 Mar 2004 08:50:06 -0800 reply

With Linux plug-ins in the 1.3 series of the GIMP, it is possible to specify with an environment variable which plug-ins you would like to debug, and on what hooks.

This debug procedure is documented in devel-docs/debug-plug-ins.txt (viewable online in http://cvs.gnome.org/bonsai/cvsblame.cgi?file=gimp%2Fdevel-docs/debug-plug-ins.txt&rev=&root=/cvs/gnome).

The commits which allow this are quite localised, and could probably be migrated fairly easily to CinePaint (see the CVS log entries for debug-plug-ins.txt for the affected files).