links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
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:

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.

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.

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