What to do if Squeak crashes or freezes


	links to this page:

Last updated at 2:52 pm UTC on 16 January 2006

There are several different levels at which a "crash" or "freeze" or other problem might occur:

VM Crash

This is the common definition of a "crash". When this occurs, Squeak will exit completely and write a stack dump to the local directory. A VM bug causing a crash like this is generally a rare occurence, though, so in this sense Squeak is "very stable" as described in How stable is Squeak?.

One somewhat common cause of VM crashes is not allocating enough memory to the Squeak VM. The VM may then crash if you attempt to allocate a large graphic element, for example. You can prevent this by assigning more memory to the VM. See FAQ: Assigning memory to the VM at startup.

It is also possible to induce a VM crash if you do some low-level mucking around in Smalltalk... see "Ways to crash a Smalltalk system" below. This isn't usually a problem for newbies or end-users.

On os-x if you have gone to the Console Application and turned the crash reporter on, then if Squeak crashs there should be a process trace file in your ~/Library/Logs/CrashReporter directory. Please email that to the macintosh VM maintainer (johnmci@smalltalkconsulting.com). Squeak should not normally crash

Freeze/Hang/Lock-Up/Infinite-Loop

If Squeak appears to have frozen, sometimes this is simply because an infinite or recursive loop is happening in Smalltalk code. You can press the interrupt key (Alt-. or Cmd-.) to break out of the loop, and a pre-debug window will appear, and things should return to normal. See FAQ: Interrupt Key.

If the interrupt key doesn't work, then the VM may have frozen (rare), or possibly a higher-level Squeak process is running amok that won't let you interrupt it. If you can repeat the problem, sometimes opening a Process Browser and turning on the CPUWatcher may help to track things down.

If you run out of memory, then it can appear Squeak is frozen because the pre-debug window can't get enough memory fast enough to appear in a reasonable amount of time.

A common way to accidentally cause a freeze on Linux/Unix machines is to perform an action (such as using the Morphic "close" halo), which attempts to generate a sound, when sound isn't fully supported on the host. This can be worked around by turning off the soundsEnabled Preference.

Error Resulting In A Debug Window

This is the pink-colored window which appears with a title such as "Message not understood", with Proceed, Abandon and Debug buttons.

This is the most common type of error/problem in Squeak, and is not really considered a "crash". It's not something you'd want end-users to run into in a running application, but it's usually not a big deal if you're playing with Squeak or programming Smalltalk. If you're coding in Smalltalk, you can press the Debug button and use the Debugger to trace through the code and determine what the problem is.

System Error Handling Failed window/Emergency Evaluator

Sometimes when coding in Smalltalk, it's possible to introduce an error or halt in one of the more fundamental display or error-reporting areas of Squeak, which prevents Squeak from bringing up a Debugger. In this case, you'll see a white "System error handling failed" window in the upper-left corner. If your most recent method change introduced this problem, you can undo it by entering the Emergency Evaluator and following the instructions (revert, exit) to revert the method change.

If a recursive halt is causing the Emergency Evaluator to appear, one trick that can help debugging is to use a "doOnlyOnce" halt like this: "self doOnlyOnce: [self halt]." This will let the halt occur only the first time, and let it proceed following times so that the debugger can come up normally. (See ProtoObject>>doOnlyOnce: for details.)

Doug Way

How can I recover my work if a crash has occurred?

If Squeak has crashed, or if you've lost power, or forgotten to save your .image file, etc., it is possible to recover your Smalltalk changes because they are always stored in the .changes file.

To do this, open the World menu and select "changes..." and then "recently logged changes...". A pop-up menu will appear asking how far back you want to browse... most likely you want to select the most recently saved image (snapshot) if the changes you've lost were made after that date.

A Recent Changes window will appear which shows changes that you've made which are in the .changes file, but may not be in your current image. Select all of the methods (and do-its) that you'd like to recover, and then choose "fileIn selections" from the pop-up menu to load them into your image. (If a particular method change or do-it caused your image to crash, be careful not to recover that particular method/do-it. :-) )

On the other hand, if you had morphs or other live content that you'd created in the image that you'd like to recover, you may be out of luck.

Ways to crash a Smalltalk system

Normally, when you crash Squeak, you've found a VM bug, which needs to be fixed, but this case is rather rare, since the VM is relatively small and is mostly auto-generated from Smalltalk code, which has been subject to a lot of debugging...

Actually, apart from VM bugs, there are ways of crashing a Smalltalk system. It's just much more difficult to do it unintentionally than in C or C++.
You can use low-level system primitives such as #become: between system-critical objects to mess up the system, or you can break basic assumptions that the VM makes without checking on every occasion:

The class structures must be consistent (superclass chain, format word, method dictionaries)
Methods must match the objects in which they are executing. If you take the method #x: from class Point and install it in class Object, you will be able to disrupt the system by sending #x: to a sufficiently well-placed object.
Introducing errors into the error-handling mechanism is a good source of infinite recursions which you cannot interrupt, because interrupts are handled by the same error-handling mechanisms.

Hans-Martin Mosner

On os-x if you have turned crash reporting on, see the console application (preferences tab crashes), then you will get a nice log of the crash in ~/Library/Logs/CrashReporter. The contents of that file for Squeak should be emailed to the macintosh VM maintainer for review.