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

Frank Shearar frank.shearar at angband.za.org
Thu Dec 23 08:37:05 UTC 2010


Words like "persistent" or "dogged" or "indefatigable" are good English 
words to describe that trait!

frank

On 2010/12/22 21:56, stephane ducasse wrote:
>
> Mariano
>
> I really want to thank you for your stubborness (probably not positive in english), I wish I could spend the time you spend on gdb and other and learn as much as you do. Keep pushing.
>
> Stef
>
>
> On Dec 22, 2010, at 10:34 PM, Eliot Miranda wrote:
>
>> Hi Mariano,
>>
>>      indeed it's a bug.  Your fix (objectMemory is: rcvr instanceOf: (self splObj: ClassBlockClosure) compactClassIndex: ClassBlockClosureCompactIndex) is the correct one.  There are a few other places where this needs to be done also.  I'll roll out new code soon.
>>
>> 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: ClassBlockClosure compactClassIndex: 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
>>
>>
>>
>>
>>
>>
>
>
>



More information about the Vm-dev mailing list