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

Vanessa Freudenberg vanessa at codefrau.net
Fri Mar 19 20:14:32 UTC 2021


On Fri, Mar 19, 2021 at 11:47 AM David T. Lewis <lewis at mail.msen.com> wrote:

>
> 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
>

Ah that makes sense. Yes, in SqueakJS it is used directly too:

https://github.com/codefrau/SqueakJS/blob/02d88e6cd5592029071c1939d85181b79a8f0d7a/vm.interpreter.js#L934


... and the easiest fix would indeed be to assign an unused primitive
number, because that would require no changes to the rest of the
execution mechanism. Putting it in the lookup phase, and caching it, seems
quite elegant. Otherwise we would have to find another place to check that
the method dict entry is actually a method, and invoke the run:with:in:
mechanism if not.

Vanessa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210319/638cf584/attachment-0001.html>


More information about the Vm-dev mailing list