Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!stan!markc From: markc@Solbourne.COM (Mark Connell) Newsgroups: comp.windows.x Subject: Re: Debugging while server grabs are present. Message-ID: <2733@stan.Solbourne.COM> Date: 11 Oct 89 13:57:13 GMT References: <126096@sun.Eng.Sun.COM> Organization: Solbourne Computer Inc., Longmont, Co. Lines: 38 In article <126096@sun.Eng.Sun.COM>, argv%turnpike@Sun.COM (Dan Heller) writes: > want to run the program from within dbx to identify where the problem > lies and to see the values of glabols. ooops... dbx stopped, but the > pointer grab is still going. You're hung. > Does anyone have a workaround for this problem? > > dan Well, it is a kludge, but it works for me: I have one of the function keys mapped to iconify/deiconify windows. If you can do this under whatever wm you are using, this may get you around the problem. If you iconify the window the pointer is grabbed in, the server will release the grab. You can then go to your dbx window, re-open your client window, .... A click-to-type wm could also get you around this problem, depending on how the click-to-type was implemented. In respones to the same question, wesommer@athena.mit.edu (William Sommerfeld) writes: > I believe that the GNU debugger lets you run an arbitrary sequence of > debugger commands when reaching a breakpoint; it also lets you make > function calls inside the target process You can also run debugger commands at a breakpoint from within dbx, but this doesn't help the problem. Dan is not stopping at a breakpoint, his client is crashing. dbx will also let you call functions, but this also doesn't help. He can't change the keyboard focus to the dbx window. Mark A. Connell Solbourne Computer, Inc. 1900 Pike Road Longmont, Co 80501 (303) 772-3400 markc@Solbourne.COM ...!uunet!stan!markc