[Vm-dev] Some protection missing (I guess in COG version)

[Eliot Miranda]

Hi Nicolas,

    good catch.  thanks.


On Mon, Dec 16, 2013 at 2:36 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> (SmallInteger new: 0) can quickly lead to a VM crash.
> This should better be intercepted as a primitive failure.
>

greed.  But there are two obvious ways to go about this (at least in Spur).
 One is to explicitly test for the immediate classes in the new and new:
primitives.  This is poor as it introduces additional tests on a critical
path.  The other way is to give SmallInteger and Character special formats
and then the primitives would fail without additional tests. The question
is what format to use.  In Spur the formats are

 0 = 0 sized objects (UndefinedObject True False et al)
 1 = non-indexable objects with inst vars (Point et al)
 2 = indexable objects with no inst vars (Array et al)
 3 = indexable objects with inst vars (MethodContext AdditionalMethodState
et al)
 4 = weak indexable objects with inst vars (WeakArray et al)
 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron)
 6 unused, reserved for exotic pointer objects?
 7 Forwarded Object, 1st field is pointer, rest of fields are ignored
 8 unused, reserved for exotic non-pointer objects?
 9 (?) 64-bit indexable
 10 - 11 32-bit indexable (11 unused in 32 bits)
 12 - 15 16-bit indexable (14 & 15 unused in 32-bits)
 16 - 23 byte indexable (20-23 unused in 32-bits)
 24 - 31 compiled method (28-21 unused in 32-bits)

Format 7 should never be valid for an instance as it is reserved by the VM
for forwarders.  So how about making 7 the format for immediate classes?
 Ten it will be easy to arrange that both new and new: will fail naturally
for this format.


I know that we cannot protect against all and every mistake, but this one
> should be easy.
>
> See
> http://stackoverflow.com/questions/20621119/how-to-print-an-integer-to-transcript
>
> I'm thinking of Spur where Character are immediate and where archeo-code
> could lead to same kind of crash.
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131216/bdf2b27b/attachment.htm