cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/19/90)
The following reached me via direct email but the reply is probably of interest to other xpert subscribers. > I have no problem running the program as it is, but when I tried to run the > program under dbx and setting a break point in the scroll list notify > handler, my olwm just went to lunch... it just locks up. Setting a > break point in the button notify routine does not cause the same problem. > I have not tried to dbx the program on a local machine yet. What has happened here is a classic case of deadlock: the window manager can't take any action until the program being debugged releases the input focus, the program being debugged can't do anything until the user instructs it to and the user can't instruct the program to continue until focus is directed to the debugger command window. This problem is not specific to scroll list notify handlers but may happen, with apparent randomness, with any callback procedure. What has happened is that the XView package has called all the necessary Xlib routines to complete its operations before calling the notify routine but Xlib has used its freedom to buffer X protocol requests so that some vital event[%] is still waiting to be sent when control enters the routine. At least one more Xlib call is required before the vital event is called but the client being debugged is never going to be able to reach one. The cure is simply to set the client into synchronous mode. The easiest way to do this without modifying the source code is to set a breakpoint on entry to main(). When the program reaches that point set the external variable _Xdebug to true. Using dbx: $ dbx client Loading 12345 symbols... done (dbx) stop in main (dbx) run stopped in main [blah, blah, blah] (dbx) assign _Xdebug = 1 -------------------------------------- [%] I don't know what the critical event or events are. Chris Flatters
dmaustin@vivid.sun.com (Darren Austin - I will not instigate revolution) (09/19/90)
In article <9009181745.AA01140@zia.aoc.nrao.edu> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: The following reached me via direct email but the reply is probably of interest to other xpert subscribers. > I have no problem running the program as it is, but when I tried to run the > program under dbx and setting a break point in the scroll list notify > handler, my olwm just went to lunch... it just locks up. Setting a > break point in the button notify routine does not cause the same problem. > I have not tried to dbx the program on a local machine yet. The cure is simply to set the client into synchronous mode. The easiest way to do this without modifying the source code is to set a breakpoint on entry to main(). When the program reaches that point set the external variable _Xdebug to true. Using dbx: $ dbx client Loading 12345 symbols... done (dbx) stop in main (dbx) run stopped in main [blah, blah, blah] (dbx) assign _Xdebug = 1 -------------------------------------- [%] I don't know what the critical event or events are. Another tip for debugging XView programs is to use the -Wfsdb command line option, which will keep XView from doing any grabs of the server. So instead of just typing "run", type "run -Wfsdb". There are other command line options that allow you to specify that only certain types of grabs shouldn't be done by XView. You can use the -help option on any XView program to find out what what is available and how to use them. Happy debugging, --Darren -- Darren Austin | All I have to do is find a Window Systems Group | one-legged nun walking a Sun Microsystems, Mountain View | goat and I win! dmaustin@sun.com |