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

[David T. Lewis]

FYI, and consistent with what you describe below, I tried running
your Squeak4.2-10966-rvm-saved.image in a StackInterpreterSimulator.
I then resaved the image from a standard interpreter VM, and ran
that re-saved image in a StackInterpreterSimulator. The one that
was re-saved can be successfully loaded into the simulator, while
the RoarVM saved image fails in #initializeExtraClassInstVarIndices,
called from #initializeInterpreter:

So the issue does appear to be in the image itself as opposed to
the image header (as I had earlier speculated).

The failure occurs in the same general area as you describe, but
the simulator detects the problem sooner (it catches an "unaligned
access" at index 7, never gets to index 11). That's about all I
can say about it, but you might want to look at it from the
simulator and see if it gives you some better clues.

To reproduce what I did, use an image with Eliot's latest
oscog VMMaker, then evaluate:

  StackInterpreterSimulator new
    openOn: 'Squeak4.2-10966-rvm-saved.image'

This will load your object memory and catch the failure in a
debugger at #initializeExtraClassVarIndices.

I note also that the standard interpreter does not have the
#initializeExtraClassVarIndices method at all, so if the failure
is specific to that initialization (as opposed to some general
corruption of the object memory), that would help explain why
the standard VM can load the image.

Dave

On Tue, Jul 19, 2011 at 11:38:54AM +0200, Stefan Marr wrote:
> 
> Hi:
> 
> Just for completeness:
> 
> /tmp/Cog$ svn info
> Path: .
> URL: 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 readImageFromFileHeapSizeStartingAt (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.
> 
> 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
> >