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 squeakml@gulik.co.nz 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:
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.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 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
squeak-dev@lists.squeakfoundation.org
-
Bryce Kampjes -
John M McIntosh -
Michael van der Gulik -
Tom Phoenix