----------------------------------------------------------------------
First, I'd recomend getting "purify" from Pure Software.  This is a
great package for tracing memory problems on Sun's.  It's a bit pricey
at $2750 but I'd still recomend it.  Excuse the marketing blurb
(contact support@pure.com for more info).

	Purify inserts additional checking instructions directly into
	the object code produced by existing compilers.  These
	instructions check every memory read and write performed by
	the program under test and detect several types of access
	errors, such as reading unitialized memory, writing past
	malloc'd bounds, or writing to freed memory.  Purify inserts
	checking logic into all of the code in a program, including
	third party and vendor object-code libraries, and verifies
	system call interfaces.  In addition, Purify tracks memory
	usage and identifies individual memory leaks using a novel
	adaption of garbage collection techniques.  Purify's nearly
	comprehensive memory access checking slows the target program
	down typically by a factor of two to five.

An alternative package that isn't as pricey ($395 for a Sun), runs on
many Unix's and has pretty similar features is "The SENTINEL Debugging
Environment".  This replaces malloc() and several other C library
functions to add additional checks.  (contact cpcahil@virtech.vti.com
for more info)

Next, if you are getting any sort of Xlib error, you'll need to run in
synchronous mode, easily accomplished with the "-sync" command line
argument or by setting the variable Xdebug to 1 with your debugger.  Then
set a break point in exit().  This will let you trace back to the
original Xlib function being called.  If you don't run in synchronous
mode, then the actual error may have occured any number of calls to
Xlib previously since the Xlib calls are buffered and replies from the
server are asynchronous.

Next, if you are having trouble with window layout, you can use the
undocumented resource "xtIdentifyWindows" or the class resource
"XtDebug" to cause the widget name to be identified with each window.
For example:

    example% xload -xrm '*XtDebug:true' &
    example% xwininfo -tree
	     <click in new xload window>

will give the normal information but the widget name and class of each
window is included.  This can help for checking the location and size
of errant widgets.

Next, if you are having trouble with geometry managers or you want to
test the way a widget manages its children, you can try
file://ftp.x.org/contrib/libXtGeo.tar.Z.  This acts as a filter
between any children and a geometry manager and checks the behaviour
of both.  It's a very clever idea.

The most unfortunate problem is debugging a callback while the
application is executing a grab of the keyboard or mouse (such as from
a pulldown menu).  The server effectively locks up and you'll need to
go to another machine and kill the debugger manually.  The server
locks up because the application being debugged has said no one else
can have access to the keyboard but the application is not stopped
waiting because the debugger is waiting for your commands.
Unfortunately you can't give them because all the input is going to
your application which is stopped.

The best way to debug this kind of problem is with two machines on
your desk, running the program under a debugger (or other environment)
on one machine, and running the application on the other, possibly
using a command sequence like this:

	othermachine% xhost +thismachine
	thismachine% setenv DISPLAY othermachine:0;
	thismachine% gdb application	# Your favorite debugger.
	or this:
	othermachine% xhost +thismachine
	thismachine% gdb application
	(gdb) set environment DISPLAY othermachine:0
	(gdb) run ...

I believe CodeCenter, a C interpreter/graphical debugger has a method
of dealing with this by explicitely calling the Xlib functions to
release any grabs during breakpoints.

Debugging widget problems requires pretty good debugging skills and
knowledge of how widgets work.  You can go a long way without knowing
the internals of a particular widget but not very far without
understanding how a widget works.  Judicious use of conditional
breakpoints and adding print statements with the debugger help a great
deal.