DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Using the graphical interface of debug

When the debugger doesn't respond

When the debugger does not respond to your mouse movements or mouse clicks, the reason may be sluggishness caused by process output or associated commands. An associated command is the optional command or list of commands you can give when creating an event. See the ``Stop'', ``Signal'', ``Syscall'', ``On Stop'', or ``Exception'' windows sections, or ``Events and command lists'' in ``Using the command line interface of debug''. The debugger gives higher priority to tracking changes in process state and running the associated commands when an event triggers than it does to responding to commands from the menus, so you may find your commands blocked out while an associated command is running. This is particularly a problem if the associated command gets into an infinite loop. The debugger will, however, respond to an interrupt, so whenever an associated command is executed, the debugger will display a notice informing you of that fact, and with a button allowing you to interrupt the associated command. If you push the OK button instead of Interrupt, and then realize you need to interrupt, click on the ``Interrupt'' button in the ``Edit menu'' of any window containing a Command pane. Even then, you may experience a delay between interrupting and the debugger again responding to your commands, as the debugger may have to process a backlog of output generated before you clicked on Interrupt.


Next topic: Using selections in the process pane
Previous topic: Streamlining threads debugging

© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 02 June 2005