[Vm-dev] CogVM/StackVM fail to read in image, fine on Squeak 4.2.1 MacVM

Eliot Miranda eliot.miranda at gmail.com
Tue Jul 19 17:38:58 UTC 2011


Hi Stefan,

On Tue, Jul 19, 2011 at 2:38 AM, Stefan Marr <squeak at stefan-marr.de> wrote:

>
> Hi:
>
> Just for completeness:
>
> /tmp/Cog$ svn info
> Path: .
> URL: http://squeakvm.org/svn/**squeak/branches/Cog<http://squeakvm.org/svn/squeak/branches/Cog>
> Repository Root: http://squeakvm.org/svn/squeak
> Repository UUID: fa1542d4-bde8-0310-ad64-**8ed1123d492a
> Revision: 2462
> Node Kind: directory
> Schedule: normal
> Last Changed Author: eliot
> Last Changed Rev: 2462
> Last Changed Date: 2011-07-16 00:35:48 +0200 (Sat, 16 Jul 2011)
>
>
>
>
> On 19/07/11 04:07, David T. Lewis wrote:
>
>>
>> On Tue, Jul 19, 2011 at 01:43:33AM +0200, Stefan Marr wrote:
>>
>> So, I took the Cog branch and the CoreVM.xcodeproj and got a VM compiled:
>>
>> #0  0x00104f80 in initializeInterpreter (bytesToShift=339693560) at
>> /tmp/Cog/macbuild/../src/vm/**gcc3x-cointerp.c:17479
>>     ccIndex = 0
>>     cct = 394155372
>>     classArrayClass = 401932980
>>     classArrayObj = 400674088
>>     header = 317718813
>>     i = 17402624
>>     i1 = 1
>>     i11 = 411556616
>>     i2 = 317431
>>     i3 = -1073746952
>>     i4 = 11
>>     index = -2
>>     oop = 10
>>
>> #1  0x00123fc0 in readImageFromFileHeapSizeStart**ingAt (f=0xa064d8e0,
>> desiredHeapSize=536870912, imageOffset=0) at
>> /tmp/Cog/macbuild/../src/vm/**gcc3x-cointerp.c:39218
>> #2  0x000652dc in main (argc=1, argv=0xbffff278, envp=0xbffff280) at
>> /tmp/Cog/macbuild/../**platforms/Mac OS/vm/sqMacMain.c:445
>>
>>
>> Where the code is:
>>
>> 17474                GIV(thisClassIndex) = i4;
>> 17475            }
>> 17476        }
>> 17477        for (i4 = (InstanceSpecificationIndex + 1); i4<=
>> (lengthOf(classArrayObj)); i4 += 1) {
>> 17478            oop = longAt((classArrayObj + BaseHeaderSize) + (i4<<
>> ShiftForWord));
>> ->  17479            if ((((oop&  1) == 0)
>> 17480&&  (((((usqInt) (longAt(oop)))>>  8)&  15)>= 8))
>> 17481&&  (((lengthOf(oop)) == 5)
>> 17482&&  ((strncmp("Array", firstFixedField(oop), 5)) == 0))) {
>> 17483                GIV(classNameIndex) = i4;
>> 17484            }
>> 17485        }
>>
>>
>> Any guesses what is going on here?
>> The following looks suspiciously like an arithmetic overflow on
>> a variable declared as sqInt:
>>
>>     i3 = -1073746952
>>
> Well, that is just thanks to the generated code which does the
> initializations on the spot.
> And, we just did not yet get to the code actually using i3.
>
> Interestingly, those initialization loops do more work then strictly
> necessary, which triggers the 'bug' here.
> Well, even if there is some problem in the image we generate, Cog just
> should not crash at that point.
>
> So, to avoid the additional work, i.e., unnecessary iterations over the
> rest of the object/array, I added the following breaks:
>
> @@ -17472,6 +17472,7 @@
>     for (i4 = (InstanceSpecificationIndex + 1); i4 <=
> (lengthOf(classArrayClass)); i4 += 1) {
>         if ((longAt((classArrayClass + BaseHeaderSize) + (i4 <<
> ShiftForWord))) == classArrayObj) {
>             GIV(thisClassIndex) = i4;
> +      break;
>
>         }
>     }
>     for (i4 = (InstanceSpecificationIndex + 1); i4 <=
> (lengthOf(classArrayObj)); i4 += 1) {
> @@ -17481,6 +17482,7 @@
> && (((lengthOf(oop)) == 5)
>
> && ((strncmp("Array", firstFixedField(oop), 5)) == 0))) {
>             GIV(classNameIndex) = i4;
> +      break;
>         }
>     }
>
> This results then in a VM which actually comes up and is functioning as far
> as I can tell.
> However, I get the following output, which might be an indication what is
> wrong with my image:
>
> mprotect(x,y,PROT_READ | PROT_WRITE): Cannot allocate memory
> squeak: could not load plugin `MiscPrimitivePlugin'
>
> (objectAfter(falseObject())) == (trueObject()) 9202
>
> (objectAfter(falseObject())) == (trueObject()) 9202
>
> ...
>
> --> "(objectAfter(falseObject())) == (trueObject()) 9202" got repeated 1985
> times in total.
>
>
> After all that, and after rewriting the generated code of the relevant loop
> into something readable, I think I understand what is going on:
>
> Looks like I have the object representing the Array class at hand, and the
> initialization tries to identify which index into a class object gives you
> the actual class name: it sets GIV(classNameIndex) (GIV = global interpreter
> variable, I suppose).
> And well, after finding this, as I said it actually is continuing to loop
> over the object slots instead of stopping which results in hitting index 11
> into that particular object.
>
> I am not sure whether I understand it correctly, but from my understanding
> it is accessing the following instance variables by index:
>
> 1: methodDict:
> 2: format:     6402
> 3: instanceVariables:     nil
> 4: organization:
> 5: subclasses:     {WeakArray . ActionSequence . WeakActionSequence .
> Cubic}
> 6: name:     #Array
> 7: classPool:     a Dictionary()
> 8: sharedPools:     nil
> 9: environment:     nil
> 10: category:     #''Collections-Arrayed''
>
>
> And the accessing 11 fails because it is not actually an instance variable.
>

Doh!  It's a one-relative/zero-relative thing.  lengthOf: returns the number
of fields in a pointer object, but i is a zero-relative variable, so the
loops need to read

InstanceSpecificationIndex + 1 to: (objectMemory lengthOf: classArrayClass)
- 1 do:
[:i|
(objectMemory fetchPointer: i ofObject: classArrayClass) = classArrayObj
ifTrue:
[thisClassIndex := i]].

Thanks for finding this!


> Is my understanding correct so far?
>
> If so, I guess the lengthOf(classArrayObj) goes wrong with my image, which
> seems to be strange somehow, because I would guess such a bug would trigger
> elsewhere, too.
>
> Best regards
> Stefan
>
>
>
>
>>
>> Dave
>>
>>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110719/c8fac227/attachment-0001.htm


More information about the Vm-dev mailing list