up next

Introduction

Whenever an unhandled error or exception occurs in Smalltalk/X, the system enters a debugger (*).

It is also possible, to enter the debugger by pressing the interrupt key "Pause" or "Interrupt" (in some older Unix configurations, use: "Ctrl-C") in any smalltalk window. This stops the corresponding process and opens a debugger on it. If you started ST/X with a controlling terminal window (console), pressing "Ctrl-C" there also interrupts the currently active process.

Finally, you can place a breakpoint dynamically on a particular method via the browser's breakpoint menu, or programatically by placing a "halt" or "breakPoint" or "assert"-message into the code. All of those messages are implemented in the Object class and therefore understood by every object.

Try evaluating:


    self halt

in a Workspace.
To open a workspace for that, press:

Modes

The debugger may run in one of three modes:

Usage

The Debugger consists of 4 major subviews plus some action buttons. Newer versions of the debugger also show a menu panel and might have the buttons split into two separate panels. The picture below may be somewhat outdated.

The actual appearance of the Debugger depends on the viewStyle setting; the picture above was taken with the "Silicon Graphics iris-style" in effect.

the subviews are:

  1. Context walkback list
  2. Method source view
  3. Receiver inspector
  4. Context inspector

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) (**).

Footnotes

(*) this is a bit oversimplified. Actually, all errors raise an exception, which (if not handled) opens the debugger. Thus the system's reaction on those errors is actually under the programmer's control.

(**) 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 located. This is a known weakness (call it "a little bug"), with which we have to live (for now).


Doc $Revision: 1.20 $ $Date: 2010/08/10 09:21:45 $