Bonobo component debugging advice, version 0.1
by Michael Meeks <mmeeks@gnu.org>


Since it is not transparently obvious how to debug Bonobo components
the following suggestions may be of use.


* Read the FAQ.

This will cover particularly common errors and their solutions obviating
the need for further debugging.


* Versions

It is vital to ensure that the correct versions of both the component
and the container are being run. The safest way to make sure this is
the case is to explicitly specify the path eg.

	./bonobo-my-component & ./my-test-container


* Correct install

It is rather important to make sure that bonobo has compiled and
installed correctly. If you are using CVS ensure that your bonobo has
installed without errors and that you have run ldconfig.


* Stale processes

It is a good idea to check there are no stale component processes
running in the background, check with

	ps ax | grep 'bonobo-my-component'
	
or just:

	oaf-slay	


* Weird stuff

If you see your components freak out in all manner of interesting
ways when the container dies read README-gdk-patch and act accordingly.
This should be fixed more elegantly shortly.


* Debugging

So: debugging. The best way to do this is to have two X-terms, in one
run the component:

	gdb ./bonobo-my-component
	$ r

And in the second run the container:

	gdb ./my-test-container
	$ r

Putting breakpoints in shared libraries such as bonobo is not possible
until they have been linked in. Hence break in main, and then start
populating your breakpoints.

Ok, so it seems some people also get horribly confused by libtool
libraries that are in fact here to help; libtool creates a shell script
in place of the binary to allow non-installed libraries to be linked
correctly. That aside you need to do:

	$ libtool gdb ./my-program-name.

NB. don't go fiddling in .libs, you will get burned.
NNB. it seems that emacs' debug mode doesn't like this; you have to
write a small 'libtool gdb' wrapper script eg. 'libtool gdb $@'


* Order of execution

It is of course important to ensure that the component has registered
before executing the container.  A good guide is to wait until your
hard disk has stopped thrashing madly before running the container.


* Assertion failure in giop-msg-buffer.c

If you get assertion failures in giop-msg-buffer.c, they may be due to
the death of the other end of the connection.  Make sure you look at
both ends of the connection.


* Desparate mesaures.

If all else fails try removing the gnome-name-service,
cleaning any installed binaries and removing
etc/CORBA/servers/bonobo-my-component.gnorba and trying again.


* Nothing seems to happen, the code just locks

Check that you are doing either a bonobo_main() or a bonobo_activate()
followed by gtk_main(). Failure to do this will cause strange lockups.
NB. must be done in both container and component.


* Request create_object, ID -N was rejected by the authentication mechanism!

The most likely cause of this warning message is initializing the goad
code via. a gnome_CORBA_init when you are using oaf; If using oaf you must

     gnome_init_	     then
     oaf_init

     instead of

     gnome_CORBA_init


* Getting more information

If you are doing serious development consider compiling gtk+, glib and
bonobo with debugging symbols:

       export CFLAGS='-g' ; ./configure

If you suspect the name server of causing problems use type:

       export GOAD_DEBUG_EXERUN=1

to get debug to the console, simply adding a breakpoint in g_log will
help get at the innards of the goad activation process.


* The last resort.

And finally when the handfuls of hair are coming out thick and fast,
consider reading the source, it only looks scary, it won't bite.


* Talk to the experts.

Try reading the mailing list archive available at:

http://www.gnome.org/mailing-lists/archives/gnome-components-list/

Alternatively if you wish to buy in the programming expertiese to meet
an agressive deadline see: http://www.gnome-support.com.