Squeak: who's afraid of the big bad "crash"?

Chris Reuter cgreuter at calum.csclub.uwaterloo.ca
Tue Dec 15 21:17:56 UTC 1998


On Tue, Dec 15, 1998 at 10:32:15AM -0500, Jeffrey Odell wrote:

[deleted--I'm actually replying to the original message, which is
currently unavailable due to NFS problems in the local environment]

> > -----Original Message-----
> > From: Paul Fernhout [mailto:pdfernhout at kurtz-fernhout.com]
> > Sent: Monday, December 14, 1998 9:09 PM
> > To: squeak at cs.uiuc.edu
> > Subject: Squeak: who's afraid of the big bad "crash"?
> >
> >
> > The expression: "SystemDictionary become: nil" crashes the 2.2 Squeak
> > Windows VM under NT 4.0. Now, admittedly, I was intentionally looking
> > for the smallest expression that will crash a Squeak system... To fix
> > this may require extra checks which would slow down the VM. I did this
> > to raise an important philosophical point about Smalltalk and "crashes".
> >
> > When I got interested in implementing VMs about fifteen years ago, it
> > was in large part to prevent bad pointer related crashes so common from
> > C or Forth or Assembler. (Of course VMs have other benefits like
> > portability...)
> >
> > Yet, I see now that I was misguided in thinking a VM would be the magic
> > bullet to avoiding "crashes". The reason is, that no matter what careful
> > structure I build on top of a VM, I can make some mistake and have that
> > structure come "crashing" down upon itself. And even if the VM has not
> > crashed, the thing I care about has. And the thing I care about may be
> > difficult to debug in its own terms due to internal complexity -- even
> > if written in Smalltalk.


You make some valid points here, and I your vision of the possiblities
available here are making me drool (metaphorically :-), but there are
a couple of things that got glossed over that I want to point out.

Firstly, yes it's true that Smalltalk is unsafe.  It's trivial to hang
the image.  However, how often do you need to manually rename classes,
or use #become:, or do any of the other clever image-crashing tricks?
It's very easy to NOT do dangerous things in Smalltalk while still
using the language to its fullest.

That's not the case with C.  In C, you HAVE to use pointers--there's
simply no choice--and minor mistakes will cause crashes.  I once spent
several days looking for a bug, to the point where I suspected the
compiler and disassembled its output, that was caused by a missing
asterisk.  Sure, you can shoot yourself in the foot in Smalltalk, but
you normally don't have to shoot at things between your toes.

The other thing is that not all memory errors cause immediate crashes.
Quite often, they do, especially on systems with really good memory
protection.  However, occasionally you get a bug that corrupts the
stack or static data.  When that happens, the bug doesn't become
noticible until long after the deed is done.

These sorts of errors are a nightmare to debug because there's no
correlation between the area of memory that was corrupted and code
that accesses it.  If struct foo gets corrupted, searching for
references to it doesn't help because the corruption happened by a
routine modifying struct bar.  Once again, these sorts of bugs can
take days to locate.  They don't always show up under testing and in
any case are often extremely difficult to reproduce.

What's worse is that the POSSIBILITY of such bugs makes it harder to
find actual logic errors, because there's no guarantee that some value
isn't spontaneiously changing due to a memory-trashing bug.  In
Smalltalk, I KNOW that when a variable is changed, the change is done
somewhere inside its scope, and that certainty really narrows things
down.

I've been using C for a decade now, and I STILL occasionally make
these sorts of mistakes, but I almost never accidentally crash or
seriously damage a Squeak image.  This is a valuable property of
Smalltalk, and one I don't want to see traded away in favour of
performance.  After all, if I need performance above all, I can always
use C++.


			--Chris 





More information about the Squeak-dev mailing list