Debugger


	links to this page:

Debugger

Last updated at 1:50 pm UTC on 31 December 2019

An essential tool in Squeak for debugging Smalltalk code.

This is the pink-colored window which appears when any Smalltalk error (such as a "Message Not Understood") occurs.

Starting in Squeak 3.1, there is also a "debug it" item added to the standard text editor pop-up menu, after "Proposal: Better Debugging (2006)", "print it" and "inspect it". If you highlight some Smalltalk code in a Workspace (such as 100 factorial) and select "debug it" from the pop-up menu, you can step through the source code implementing factorial to see how it works. This can be a great way to learn Smalltalk... often better than looking at code in a Browser.

If you have written some code and it does not work as you expect. You may put the breakpoint to your code. Putting the breakpoint into the code means that you insert the following statement at the appropriate place:

self halt.

If some of the Squeak's processes comes to that point. You will see something like this:

Uploaded Image: Halt.gif

It may seem horrible at the first glance - BUT - it is really wonderful thing. You see a window with the two panes. The upper pane contains three buttons:

Proceed
Abandon
Debug

The Proceed button resumes the interrupted process which you are debugging. The Abandon button terminates the process you are debugging. The Debug button opens another even more wonderful window (see below).

The lower pane contains the lists the stack frames (or method context) of your process. Simply said it depicts the nested method invocations.

The top of this list contains the invocation of the
```
UndefinedObject>>halt
```
method you have put in the method.
The second item from the stack contains the invocation of the method to which you have put the
```
self halt
```
statement - in our example, this is UndefinedObject>>DoIt. (This is the frame you are usually interested in the most).
The third item from the stack contains the the frame which invoked the method into which you have added the
```
self halt.
```

If you click on the arbitrary frame, the debugger window opens and shows you the situation exactly in that frame.

Uploaded Image: Halt1.gif

There are several panes there. We will describe it from top to down.

frame pane: The topmost frame lists the frames (or method contexts). You can click at any of the frames and the source pane will show the code of the appropriate method.
button pane: contains the following buttons:
- Proceed: enables you to let the current process run to the next breakpoint (if any).
- Restart: restarts the execution of the current method context.
- Into: if the debugger is going to execute some message expression, with this button you step into appropriate method.
- Over: if the debugger is going to execute some message expression, with this button you can step over this expression (i.e. you will not enter the code of the appropriate method). Debugger executes that message-expression and moves the cursor at the next one.
- Through: if the debugger is going to execute a block, with this button you can step though this block.
- Full Stack: if the current stack is very large, the debugger will not show it completely. Click this button to display the stack in its full length.
- Where: selects the statement that will be executed next.
source pane: Shows the code of the frame selected in the frame pane
At the bottom, there are four small panes organized horizontally. They enable you to select and view the instance variables and temporary variables of the current context. You can open them in the Inspector or the Object Explorer.

Debugging of the "multi-threaded" application is also possible. In this case each of the processes will have its own debug window.

See also Proposal: Better Debugging (2006) and Better Debugger.

Note: In rare cases, the debugger might fail itself and raise an infinite chain of debuggers (for example, see http://forum.world.st/The-Inbox-Morphic-ct-1610-mcz-td5108228.html). We are currently working on fixing this problem, but if you run into a situation where you cannot use the debugger, a workaround is to insert

self inform: #halt

before an error is raised, or

thisContext veryDeepCopy explore

in order to analyze the current call stack, including all stackframes and variables.

Debugger model