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.