deano@raistlin.uucp (dean mason - 535-4717) (02/09/91)
Has anyone had the pleasure of trying to debug an xview program with dbxtool. Maybe it is just my setup but I am running an IPC with fullup SunOS 4.1.1 straight off the tape. The problem is that when I set a breakpoint inside one of my callbacks, it stops all right, the whole damn window manager locks up! I suspect (hopefully incorrectly) that this is due to the implementation of event handling through a central "notifier" and that the notifier is perhaps "hung" waiting on the event I trapped to finish? Is this the problem? Any work arounds? I haven't tried it with straight dbx, but I've seen the exact same thing with adb. How are we supposed to debug xview applications without a debugger? deano@raistlin.udev.cdc.com
shiffman@Sun.COM (Hank Shiffman) (02/09/91)
In article <30451@shamash.cdc.com>, deano@raistlin.uucp (dean mason - 535-4717) writes: > > The problem is that when I set a breakpoint inside one of > my callbacks, it stops all right, the whole damn window manager > locks up! What you're running into relates to something in X called "grabs". The X application grabs the keyboard, mouse and server, which doesn't let anyone else in to do anything. Fortunately, there is a simple solution: set one of the fullscreen- debug variables in dbx or your program, which will disable this global grabbing. For example, put the -Wfsdb or -fullscreendebug switch on the run command. Look on page 139 of the XView Version 2 manual Converting SunView Applications for all the details. -- Hank Shiffman (415) 336-4658 Marketing Technical Specialist Sun Microsystems, Inc. shiffman@Eng.Sun.COM
dmaustin@vivid.sun.com (Darren Austin) (02/09/91)
In article <30451@shamash.cdc.com> deano@raistlin.uucp (dean mason - 535-4717) writes:
Has anyone had the pleasure of trying to debug an xview program
with dbxtool. Maybe it is just my setup but I am running an
IPC with fullup SunOS 4.1.1 straight off the tape.
The problem is that when I set a breakpoint inside one of
my callbacks, it stops all right, the whole damn window manager
locks up! I suspect (hopefully incorrectly) that this is due to
the implementation of event handling through a central "notifier"
and that the notifier is perhaps "hung" waiting on the event I trapped
to finish? Is this the problem? Any work arounds? I haven't tried
it with straight dbx, but I've seen the exact same thing with adb.
How are we supposed to debug xview applications without a debugger?
Try running the program inside dbxtool with "run -Wfsdb" (full
screen debug). This will shut off attempts by the XView library
to grab the server, which I believe is the problem you are
running into. You might want to take a look at the man page on
xview (1) for more information on the debugging options available
to you from the command line.
Hope this helps,
--Darren
--
Darren Austin | Actually, it's a buck and a quarter
Windows and Graphics Software | staff, but I'm not going to tell
Sun Microsystems, Mountain View | *him* that.
dmaustin@sun.com |toone@looney.Corp.Sun.COM (Nolan C. Toone) (02/10/91)
In article <30451@shamash.cdc.com> deano@raistlin.udev.cdc.com writes: > >Has anyone had the pleasure of trying to debug an xview program >with dbxtool. > >The problem is that when I set a breakpoint inside one of >my callbacks, it stops all right, the whole damn window manager >locks up! > >How are we supposed to debug xview applications without a debugger? > My opinion of what is happening: the callbacks are grabbing the screen and waiting for specific input from the notifier. the dbx (as part of the windows) has the process stoped. no input to the process because dbx has it stopped and no input to dbx be cause the process has the focus. Temporary solution: Use /bin/dbxtool. This is the sunview dbxtool that runs under sunview compatability mode. Sunview goes directly to/from the system bypassing the window manager etc. so **IT** won't hang. (Every thing else will but as soon as you exit dbxtool they all return). Long term solution: Hope a solution comes out before sunview dbxtool disappears. Nolan Toone
holtz@netcord.Eng.Sun.COM (Brian Holtz) (02/15/91)
In article <30451@shamash.cdc.com> deano@raistlin.udev.cdc.com writes: > >The problem is that when I set a breakpoint inside one of >my callbacks, it stops all right, the whole damn window manager >locks up! Run your program with the -fullscreendebug option, so that it will disable server grabs by XView. -- Brian Holtz
rlh2@ukc.ac.uk (R.L.Hesketh) (02/18/91)
In article <3385@jethro.Corp.Sun.COM> toone@looney.Corp.Sun.COM (Nolan C. Toone) writes: >In article <30451@shamash.cdc.com> deano@raistlin.udev.cdc.com writes: >>Has anyone had the pleasure of trying to debug an xview program >>with dbxtool. >My opinion of what is happening: > no input to the process because dbx has it stopped >and no input to dbx be cause the process has the focus. Have you tried setting the display of the xview program to a different display that you are running dbxtool on (using -display as an argument to the program)? The xview program would then be displayed on this different display allowing dbxtool to function normally even when the xview program's process has hit a break point whilst in a server grab etc. It also makes debugging actions such as rubber-banding and other pointer grab techniques a breeze (you can get a friend to hold the buttons down whilst you scan the source 8-). Richard
andrew@resam.dk (Leif Andrew Rump) (02/19/91)
In <3385@jethro.Corp.Sun.COM> toone@looney.Corp.Sun.COM (Nolan C. Toone) writes: >In article <30451@shamash.cdc.com> deano@raistlin.udev.cdc.com writes: >>The problem is that when I set a breakpoint inside one of >>my callbacks, it stops all right, the whole damn window manager >>locks up! >Long term solution: >Hope a solution comes out before sunview dbxtool disappears. Specify the -Wfsdb (-fullscreendebug) flag, when you start dbxtool! Leif Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 51 54 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark > > Read oe as: o <backspace> / (slash) and OE as O <backspace> / (slash) < <