![]() |
![]() |
![]() |
Libmatecomponent Reference Manual | ![]() |
---|
MateComponent component debugging advice, version 0.1 by Michael Meeks <mmeeks@gnu.org>
Since it is not transparently obvious how to debug MateComponent components the following suggestions may be of use.
This will cover particularly common errors and their solutions obviating the need for further debugging.
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.
./matecomponent-my-component & ./my-test-containerIt is rather important to make sure that matecomponent has compiled and installed correctly. If you are using CVS ensure that your matecomponent has installed without errors and that you have run ldconfig.
It is a good idea to check there are no stale component processes running in the background, check with
ps ax | grep 'matecomponent-my-component'or just:
matecomponent-slaySo: debugging. The best way to do this is to have two X-terms, in one run the component:
gdb ./matecomponent-my-component $ r
And in the second run the container:
gdb ./my-test-container $ r
Putting breakpoints in shared libraries such as matecomponent 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 $@
'
There is beautiful built in MateCORBA2 method tracing
facility that will show you all CORBA invocations,
their objects, arguments, microsecond timestamps
etc. To use it you need to configure MateCORBA2 with the
--enable-debug switch and then either define the
environment variable MATECORBA2_DEBUG
or
use the ORBDebugFlags command line option or matecorbarc
flag. See the MateCORBA2 FAQ for more info.
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.
export MATECOMPONENT_ACTIVATION_DEBUG_OUTPUT=1 matecomponent-slay
And try again - it's possible that a debug message is being suppressed by matecomponent-activation-server that this will show you.
Check that you are doing either a
matecomponent_main()
or a
matecomponent_activate()
followed by
gtk_main()
. Failure to do this
will cause strange lockups, caused because the POA is
still queueing incoming requests waiting to be
activated. NB. this must be done in both container
and component.
If you are doing serious development consider compiling gtk+, glib and matecomponent with debugging symbols:
export CFLAGS='-g' ; ./configureIf you suspect the name server of causing problems use type:
export MATECOMPONENT_ACTIVATION_DEBUG_EXERUN=1to get debug to the console, simply adding a
breakpoint in g_log
will help get
at the innards of the matecomponent-activation
process.
This is often best done by running:
gdb ./matecomponent-activation r --ac-activate
And then cutting and pasting the IOR it spews out into /tmp/matecorba-$USER/reg:...-local.
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.
Try reading the mailing list archive .
Alternatively if you wish to buy in the programming expertise to meet an agressive deadline see: http://www.mate-support.com.