Segmentation faults and friends.

Hi all.

This is a rather philosophical question: is it a bug if the VM crashes,
showing either a General Protection Fault, Segmentation Fault and core
dump, or whatever the local operating system does?

I've discovered a few ways of generating segmentation faults (under
Linux) using Squeak. One was playing around with CompiledMethods; I
accidently broke a literal reference such that when the garbage
collector ran, Squeak crashed.

This may or may not be a bug depending on whether you want to add bounds
checking to the garbage collector, which may have a performance penalty.

Another way is the following, done in the workspace:

b := BlobMorph class.
m := Metaclass new.
m superclass: (b superclass) methodDictionary: (b methodDictionary)
format: 2.
t := m new.
t class printIt.

In this case, format is invalid. It should be 152. Here, I was just
being stupid.

So the question, again, is: should the VM *never* crash and protect
against very curious, stupid programmers like myself, or should it work
fine until the programmer becomes curious and stupid?

Michael.

On 3/27/06, Michael van der Gulik <[hidden email]> wrote:

> This is a rather philosophical question: is it a bug if the VM crashes,
> showing either a General Protection Fault, Segmentation Fault and core
> dump, or whatever the local operating system does?

It's _somebody_'s bug. Unless it's your desired outcome, of course. :-)

> So the question, again, is: should the VM *never* crash and protect
> against very curious, stupid programmers like myself, or should it work
> fine until the programmer becomes curious and stupid?

A sufficiently curious programmer is capable of crashing any system;
stupidity is not a requirement. :-)

Still, in some of the places where the VM crashes today, it may have a
way to recover tomorrow. It should IMHO be sufficiently robust that it
doesn't crash until you've done the software equivalent of dropping a
wrench in the gears. In other words, when you crash it, you should
know (or easily be able to determine) why it's your own fault. If
Squeak isn't this stable today, it's pretty close.

If you find that the VM crashes when you think it should recover,
maybe you can cook up a patch. Or, at least, file a bug report on
Mantis. We'll never see a Squeak that can't crash, but it should be
stable enough for all normal uses.

Cheers!

--Tom Phoenix

If you look at the VisualWorks source code you'll see it's much more  
paranoid about things and the test flavor does asserts *everywhere*  
to confirm sanity so with it it's less likely to die if you do  
something clever, still developers from time to time come up with  
cleverer code so to speak.


For the most part the Squeak VM does not do sufficient error  
checking, that said usually the errors encountered are related to  
platform support code, any such GPF, Seg Faults etc should be  
reported in Mantis, and of course I welcome the chance to look at any  
os-x crash logs.

On 27-Mar-06, at 10:18 PM, Michael van der Gulik wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Michael van der Gulik writes:

 > Another way is the following, done in the workspace:
 >
 > b := BlobMorph class.
 > m := Metaclass new.
 > m superclass: (b superclass) methodDictionary: (b methodDictionary)
 > format: 2.
 > t := m new.
 > t class printIt.
 >
 > In this case, format is invalid. It should be 152. Here, I was just
 > being stupid.
 >
 > So the question, again, is: should the VM *never* crash and protect
 > against very curious, stupid programmers like myself, or should it work
 > fine until the programmer becomes curious and stupid?

In this case I'd say it's OK for the VM to crash. It might
be better for #superclass:methodDictionary:format: to validate
the format argument.

Ideally, we want the system to be robust but we also want it
to be flexible, live changeable, and fast. There are many things
that the VM doesn't check which can easily cause crashes but
are normally checked elsewhere. The size of the stack when pushing
arguments is an example. The stack size is checked by by the
byte code compiler.

Try editing the collection hierarchy. It's easy to break the system
without needing to involve the VM. The system robust in normal use.
It is also easy to change. It shouldn't crash when people are doing
normal programming but if you want to experiment in the guts of it it
also shouldn't stop you.

Crashes are a learning experience.
Bryce

> From: Michael van der Gulik
> should the VM *never* crash and protect
> against very curious, stupid programmers like myself, or
> should it work
> fine until the programmer becomes curious and stupid?

It should work find until programmers become curious and stupid.
Curious and clever programmers experiment using InterpreterSimulator...

                - Peter, tongue in cheek