"halt"-message,
which is understood by every object.
Try evaluating:
self halt
in a workspace.
Finally, pressing the interrupt key "CNTL-C"
(Windoze: "Pause" or "Interrupt" )
in any view stops the corresponding process and opens a debugger on it.
The debugger may run in one of three modes:
Any number of these normal debugViews may be open concurrently.
Only one modal debugView may be open at any time. Under normal conditions, the system does never enter this model debugger (we worked hard to avoid it, by caring for most possible errors in the event handling code).
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 (or simply double click on a process entry in its list).
Any number of these inspecting debugViews may be open concurrently.
The Debugger consists of 4 major subviews plus some action buttons (new versions of the debugger also show a menu panel - this is not shown in the somewhat outdated screen shot below);
(the actual appearance of the Debugger depends on the viewStyle setting; the picture above was taken with the "iris-style" in effect)
the subviews are:
The context walkback list shows the context chain which lead to the exception (i.e. starting at the current context on top, the list of senders is displayed). It should be read bottom to top.
Selecting a context in this list will show the corresponding methods source in the method source view.
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.
This view is a codeView - which means that you can change the code and "accept"
to change the method (i.e. fix errors and compile). However, once accepted,
the source code of the method is no longer in sync with
the state of the process (since that one is still suspended in the previous, old code).
To avoid confusion, the debugger hides all stack frames up to and including the one
in which the accept occurred.
You can also evaluate expressions (like in a workspace) in any of the views. Variable references are resolved as usual (i.e. you can refer to local variables, class variables, instance variables etc. as if the code was written in a normal method) (**).
(**)
Ocasionally, the debugger has trouble with this, as the compiler(s) move
local variables of inlined blocks into their surrounding context
(i.e. a local variable within an ifTrue:[]-block is typically moved to the
methods stack frame).
Although trying hard, the debugger sometimes gets a wrong idea of where the variable
is actually stores.
This is a known weakness (call it "a little bug"), with which we have to live (for now).