Whenever an error occurs in Smalltalk/X, the system enters a debugger
(*).
It is also possible, to enter the debugger via the "halt"
-message,
which is understood by every object.
Try evaluating:
self halt
in a workspace.
Finally, pressing CNTL-C
in any view stops the corresponding process and opens a debugger on it.
The debugger may run in one of three modes:
- normal
whenever an error occurs in a process,
which is not the event handler process or scheduler,
the debugger will start up on top of the erronous process,
blocking all interaction with the affected process
(and its views).
Other views are still active and behave as usual.
Any number of these normal debugViews may be open concurrently.
- modal
when an error occurs in smalltalks event handler process or scheduler,
the debugger starts up modal.
While a modal debugger is active,
NO interaction with other views is possible.
(the reason is simple: if the eventhandler process was blocked,
the debugger itself could not communicate with you any more -
therefore the debugger starts its own modal event handling loop
- effectively disabling all other event handling.)
As a consequence, opening debuggers or inspectors from a modal debugger
does not work correctly (the views will show up delayed: later when the
normal event processing is continued).
Only one modal debugView may be open concurrently.
- inspecting
this mode allows inspecting the state of other processes;
it can be opened from the ProcessMonitor.
However, since the debugged process may continue to run,
it is only possible to inspect a "snapshot" of the affected process.
As soon as the process continues to run,
the information presented by the debugger may become obsolete.
This also means,
that the debugger can not show any position (i.e. line) information for contexts
which have already returned.
Inspecing debuggers are useful to inspect blocked processes,
and allow to resume them
(by signalling the semaphore the process is waiting for)
or to terminate the process.
The process monitor offers a pop up menu function to start
an inspecting debugger on any process.
Any number of these inspecting debugViews may be open concurrently.
The Debugger consists of 4 major subviews plus some action buttons;
(Notice: the above picture was taken with version 10.3 of ST/X.
Later versions may provide more functions.)
the subviews are:
- context walkback list
- method source view
- receiver inspector
- context inspector
The context walkback list shows the context chain which lead to
the error (i.e. starting at the current context on top, the list of senders
is displayed).
Selecting a context in this list will show the corresponding methods
source in the method source view, with the current line highlighted.
The recevier inspector allows inspection of the receiver of the
selected message and the context inspector provides information
about the arguments and local variables of this context.
The method source view highlights the current position of execution initially.
This is a CodeView - which means that you can change the code and "accept"
to change the method (i.e. fix errors and compile).
Footnotes
(*)
this is a bit oversimplified. Actually, all errors raise a signal,
which then (if not handled) opens the debugger.
Thus the behavior on those errors is actually under the programmers
control.