[comp.windows.x] Debugging Graphics Programs

marler@evax.arl.utexas.edu (T. Gordon Marler) (09/16/90)

I'd like to debug a program I've written in X that simply opens a window
and draws in it.  However, when I use dbx or gdb, the window does not
open nor can I see any graphics being drawn as the program executes.  If
I simply execute the program, it opens its window and draws in it just
fine.  How can I get the debugger to open the window and draw into it as
the program executes?

Gordon Marler
marler@evax.arl.utexas.edu

jimf@SABER.COM (09/17/90)

|I'd like to debug a program I've written in X that simply opens a window
|and draws in it.  However, when I use dbx or gdb, the window does not
|open nor can I see any graphics being drawn as the program executes.  If
|I simply execute the program, it opens its window and draws in it just
|fine.  How can I get the debugger to open the window and draw into it as
|the program executes?

You're seeing the effects of buffering.  Put in code to turn X
debugging mode on, which makes the calls fully synchronous for easy
debugging but which slows performance somewhat:

	main()
	{ Display *disp;

	  /* set up display variable */
	  XSynchronize(disp, 1);
	  /* do your thing... */
	}

This can also be accomplished by setting the _XDebug flag to true:

	extern _XDebug;

	main()
	{
	  _XDebug= True;
	  /* do your thing... */
	}

Alternatively you can call XFlush before a breakpoint.  In Saber-C you
can use the following action point:

	{ XFlush(disp); saber_stop(""); }

jim frost
saber software
jimf@saber.com

ekberg@ti-csl.csc.ti.COM (09/17/90)

The problem is that Xlib normally buffers up requests for you so reduce network
traffic.  When you put the breakpoint after the call to XMapWindow Xlib may
still have that request in its buffer.

What I do is to 

		extern int _Xdebug;

and then put the following near the top of my program:

	  /* Synchronize errors.  See page 46 of Adrian Nye's Xlib Programming
	     Manual, volume 1.  0 means off, 1 means synchronize. */
	  _Xdebug = 1;

This will slow down your program, but that is normally OK for debug purposes.
This will cause Xlib to not buffer your requests, so setting a breakpoint
after the call to XMapWindow will allow you to see the window.

  -- tom (aisle C-4Q), ekberg@csc.ti.com

moraes@cs.toronto.edu (Mark Moraes) (09/18/90)

Or, if you're using Xt as all good X programmers should (:-), just
run the program with the -sync option...

dtomm@sparcplug.us.oracle.com (Doug Tomm) (09/18/90)

Somebody wrote:

> I'd like to debug a program I've written in X that simply opens a window
> and draws in it.  However, when I use dbx or gdb, the window does not
> open nor can I see any graphics being drawn as the program executes.  If
> I simply execute the program, it opens its window and draws in it just
> fine.  How can I get the debugger to open the window and draw into it as
> the program executes?

Try using XSynchronize.  You should do something like the following:

			:
			:
			:
		dpy = XOpenDisplay(displayname);
		if (!dpy)
			bail(out);
#ifdef DEBUG
		XSynchronize(dpy, 1);
#endif /* DEBUG */
			:
			:
			:

XSynchronize will enable synchronous event reporting (disabled with
XSynchronize(dpy, 0)).  This will cause the effects of events to
appear immediately, so that you can see what happens as you step
through a debugger.

Bracketing the XSynchronize as above is important because XSynchronize
will make your application run much slower.

Another way to turn on synchronous mode is to call XSynchronize from
within dbx (I don't know how to do this from within GDB).  Set a
breakpoint before your event handler, and type

	(dbx) call XSynchronize( mydpy, 1 )

where mydpy is the display pointer returned by XOpenDisplay (make sure
it isn't null).  The second approach is useful when debugging toolkit
applications.

Doug Tomm
Oracle Corporation
dtomm@oracle.com

My wife love me.  We don't agree all the time.  Oracle loves me a lot
less.  You figure it out.