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
© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 27 April 2004