[Vm-dev] regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)

David T. Lewis lewis at mail.msen.com
Fri Mar 19 18:47:28 UTC 2021


On Fri, Mar 19, 2021 at 09:11:52AM -0700, Vanessa Freudenberg wrote:
>  
> On Mon, Mar 1, 2021 at 16:05 David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > On Mon, Mar 01, 2021 at 06:20:58PM +0100, stes at PANDORA.BE wrote:
> > >
> > > > Install primitiveArrayBecomeOneWayNoCopyHash as primitive 248
> > > > replacing obsolete primitiveInvokeObjectAsMethod.
> > >
> > > Any news on this Tests-ObjectsAsMethods issue ?
> > >
> > > The purpose of those tests are not clear to me;
> > >
> > > Perhaps the change for the "primitives" which was made, can be reverted ?
> > >
> > > Possibly that creates a new problem for
> > primitiveArrayBecomeOneWayNoCopyHash.
> > >
> > > David Stes
> > >
> >
> > You can consider this a bug in the most recent interpreter VMs. I had
> > failed to notice that there is a hard coded reference to that primitive
> > number within the VM itself, and this reference is now resulting in
> > invocation of the wrong function.
> >
> > A trivial fix is to rearrange some primtive number assignments, but the
> > correct thing to do is adopt the logic that Eliot uses in oscog so that
> > the function is not invoked as a "primitive" at all.
> >
> > I'll try to follow up on this next week.
> >
> > Dave
> 
> 
> 
> This test crashes SqueakJS, too. Could be the same primitive reassignment
> confusion.
> 
> Can you describe this ???hard coded reference???? Under what circumstances is a
> primitive being called without being an actual primitive?
> 

Hi Vanessa,

Sorry I did not think about SqueakJS and yes I am sure it is the same issue.

The hard coded reference to primitive 248 is in ContextInterpreter>>lookupMethodInDictionary:
which assumes that primitiveInvokeObjectAsMethod is installed as primitive 248.

I tried assigning primitiveInvokeObjectAsMethod to primitive number 575 in
initializePrimitiveTable (last available entry in the current table, which
appeared to be unused), and changed lookupMethodInDictionary: to call 575
rather than 248.

That worked fine until I tried running a trunk-level V3 image, which failed
because we are now calling primitive 575 for primitiveHighBit.

I'm sure there's some other primitive number we could use to hide
primitiveInvokeObjectAsMethod elsewhere in the primitive table, but this
approach seems obviously wrong to me, and the right thing would be to do
whatever Eliot did in oscog to avoid trying to pretend that this method
is a primitive (which it is not despite its name).

At that point I had no more time to follow up on this, sorry. But that's
where the problem lies, and I'm sure there is a way to do this correctly
based on Eliot's implementation.

Dave



More information about the Vm-dev mailing list