[Vm-dev] primitivePerform (prim 83) | primitivePerformInSuperclass (100)

Eliot Miranda eliot.miranda at gmail.com
Mon Dec 12 19:46:44 UTC 2011

Hi Stefan,

On Mon, Dec 12, 2011 at 12:53 AM, Stefan Marr <squeak at stefan-marr.de> wrote:

> Hi Dave,
> Hi Eliot:
> On 12 Dec 2011, at 02:42, David T. Lewis wrote:
> > I think you are missing some arguments for the primitive in your
> > #performSuper methods.
> Thanks Dave, indeed. Was certainly to late for me yesterday.
> I forget the class, in which the lookup is supposed to be started.
> Eliot, well, there was another argument, which was probably interpreted as
> the lookup class but was just a SmallInteger instead. Guess that was
> causing the crash.

The problem was that you declared a primitive with too few arguments and
this interacted badly with the VMs interpreted frame format.  You have a
Object>performSuper: aSymbol with: anObject
"Send the selector, aSymbol, to the receiver with anObject as its argument.
Fail if the number of arguments expected by the selector is not one.
Primitive. Optional. See Object documentation whatIsAPrimitive."

<primitive: 100>
^ self perform: aSymbol withArguments: (Array with: anObject) inSuperclass:
self class superclass

which only declares two arguments even though primitive 100,
perform:withArguments:inSuperclass: requires three.  So when the primitive
attempted to access the receiver it actually fetched the field below, which
happens to be the interpreted frames' saved ip which is null in this case.
So the VM dies trying to follow a null pointer when it tries to fetch the
receiver's class (since 0 is not a SmallInteger).

0xbff5d7a4 I OstCompilerTestDomain(OstDomain)>requestSuperExecutionOf:on:
367331552: a(n) OstCompilerTestDomain
0xbff5d7b4:   rcvr/clsr: 0x15e508e0     =a(n) OstCompilerTestDomain
0xbff5d7b0:        arg0: 0x14d482ec     =#xx_omni_x_b
0xbff5d7ac:        arg1: 0x15e508c8     =a(n) OstCompilerTestSubjectSub
0xbff5d7a8:   caller ip: 0x1380fc8e=327220366
0xbff5d7a4:    saved fp: 0xbff5d7c4=-1074407484
0xbff5d7a0:      method: 0x1531683c     0x1531683c 355559484: a(n)
0xbff5d798:intfrm flags:      0x201=513  numArgs: 2  hasContext: 0
 isBlock: 0
0xbff5d79c:     context: 0x1383c004     =nil
*0xbff5d794:    saved ip:        0x0 0*
0xbff5d790:    receiver: 0x15e508e0     =a(n) OstCompilerTestDomain
0xbff5d78c:        stck: 0x15e508c8     =a(n) OstCompilerTestSubjectSub
0xbff5d788:        stck: 0x14d482ec     =#xx_omni_x_b

It dies at this line in primitivePerformInSuperclass trying to access the
receiver's header:
*32747           if (((ccIndex = (((usqInt) (longAt(rcvr))) >> 12) & 31))
== 0) {*
32748                   currentClass = (longAt(rcvr - BaseHeaderSize)) &
32749                   goto l1;

Now the VM has support for checking primitive argument counts, and it will
fail a primitive if the number of arguments dropped from the stack is
incorrect.  But it can only check the number of arguments after the
primitive has run.  So alas since the crash happens before the prtimitive
has finished you are, in the classic phrase, SOL.  Sorry :)

BTW, the saved ip is the bytecode address at which to resume execution in
the interpreter.  The return address of the next frame will be e.g.
ceReturnToInterpreter so that when a machine code frame returns to an
interpreted frame it returns to a trampoline which then reenters the
interpreter and resumes execution at the bytecode pointed to by saved ip.

> From the RoarVM interpreter I understand that the lookup class is not
> crosschecked for being a class. I think it did work on the interpreter for
> me, because my patched DNU handler is 'a bit to robust', and does not
> exactly what it is supposed to do.
> Thanks
> Stefan
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111212/087d15d5/attachment.htm

More information about the Vm-dev mailing list