[Vm-dev] [COG] primitiveClosureValue assert is failing with StackVM (possible BUG in bytecodes!!)

[Mariano Martinez Peck]

On Wed, Dec 22, 2010 at 10:34 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
> Hi Mariano,
>
>     indeed it's a bug.  Your fix (objectMemory is: rcvr instanceOf: (self
> splObj: ClassBlockClosure) compactClassIndex:
> ClassBlockClosureCompactIndex) is the correct one.
>

Thanks Eliot. But with that fix, the buytecode primitives are still failing
and not calling the primitive, but commonSend. So:

1) is this the expected behavior .. or
2) to fix that is not as I did it in my last fix but in some other place
that you will fix?



>  There are a few other places where this needs to be done also.  I'll roll
> out new code soon.
>

Ok. Please let me know. I have some changes for better support of
SmallIntegers as methods. I can provide them if you want.

Cheers

mariano


>
> best
> Eliot
>
> On Wed, Dec 22, 2010 at 12:03 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>> Hi Eliot. If I compile a StackVM, and I just press the left arrow in a
>> code pane of a OB windows, in a pharo image, I get an asser that fails:
>> (oop & 1) 19202
>>
>> Sorry I bother with these asserts, but I am trying to solve the crashes I
>> have and I think starting for the asserts is a good idea.
>>
>> The assert that fails is in primitiveClosureValue()  the part:
>>
>> blockClosure = longAt(GIV(stackPointer) + (GIV(argumentCount) *
>> BytesPerWord));
>>     /* begin quickFetchInteger:ofObject: */
>>     oop = longAt((blockClosure + BaseHeaderSize) + (ClosureNumArgsIndex <<
>> ShiftForWord));
>>     assert((oop & 1));
>>     numArgs = (oop >> 1);
>>     if (!(GIV(argumentCount) == numArgs)) {
>>         /* begin primitiveFail */
>>         if (GIV(primFailCode) == 0) {
>>             GIV(primFailCode) = 1;
>>         }
>>         return;
>>     }
>>
>>
>> numArgs results to be a large number (using #printNum:   was 718613205),
>> and if I try to do a #printOop:  I got a " 0x55aa55aa0x55aa55aa is not on
>> the heap"
>>
>> Now, of course, the "if (!(GIV(argumentCount) == numArgs)) " fails.
>>
>> What it is funny is that I did a #printOop: of blockClosure instVar, and
>> this is what I get:  0x1f59b578: a(n) Association
>>
>> Association? WTF ?   so...I guess something weird is happening. I continue
>> debugging it..and I noticed that:
>>
>> - Several classes were called in addition to Association,like Character.
>> These seems to be compact classes and implement #value and #value:   ;)
>> - Both, #bytecodePrimValue and #bytecodePrimValueWithArg  were not calling
>> #primitiveClosureValue. So, "isBlock" was false...
>>
>> I tried modifying #bytecodePrimValueWithArg and #bytecodePrimValue  this
>> line:
>>
>> isBlock := objectMemory is: rcvr instanceOf: ClassBlockClosurecompactClassIndex: ClassBlockClosureCompactIndex.
>>
>> to this one:
>>
>> isBlock := objectMemory is: rcvr instanceOf: (self splObj:
>> ClassBlockClosure) compactClassIndex: ClassBlockClosureCompactIndex.
>>
>> WIth this change, at least, the assert doesn't fail anymore. I made
>> progress (maybe). But still, for normal closures, "isBlock" seems to be
>> false. So.....all block values are being managed as a normal send ????
>>
>> Now, I don't understand why ClassBlockClosureCompactIndex  is 0. I think
>> this may be the problem. Why it is not 12? (in Pharo  Smalltalk
>> compactClassesArray at: 12 ->>> BlockClosure.)
>> I notice that ObjectMemory >> initializeCompactClassIndices  does:
>>
>>     ClassBlockClosureCompactIndex := 0 "12". "Prospective.  Currently
>> TranslatedMethod class"
>>
>>
>> Notice that this ZERO changes the sematic of #is: oop instanceOf: classOop
>> compactClassIndex: compactClassIndex
>> called from the #bytecodePrimValue and bytecodePrimValueWithArg
>>
>> Finally, I changed the mentioned line to this:
>>
>> isBlock := objectMemory is: rcvr instanceOf: (self splObj:
>> ClassBlockClosure) compactClassIndex: 12.
>>
>> and finally, with block closures, it is calling the primitive, and for
>> Association it doesn't fail the assert.  ahh and the image doesn't crash ;)
>>
>> I don't know if this is a bug, if my solution was ok, nor it impact.
>> Please let me know.
>>
>> Cheers
>>
>> Mariano
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101223/996e3efa/attachment.htm