[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