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

[David T. Lewis]

On Tue, Jul 19, 2011 at 01:43:33AM +0200, Stefan Marr wrote:
> 
> Hi:
> 
> On 18/07/11 15:01, Stefan Marr wrote:
> >
> >Hi Dave:
> >
> >On 18/07/11 14:34, David T. Lewis wrote:
> >>
> >>On Mon, Jul 18, 2011 at 02:02:10PM +0200, Stefan Marr wrote:
> >>>However, now I noticed that the CogVM/StackVM crash when they are asked
> >>>to load an image which is saved by our RoarVM.
> >>>
> >>>The Cog/StackVM fail to open it with an error in "0
> >>>org.squeakfoundation.Squeak       0x00033462
> >>>readImageFromFileHeapSizeStartingAt + 3058"
> >>>
> >>>[1] http://soft.vub.ac.be/~smarr/roarvm/squeak-saved-with-rvm.zip
> >I took the standard stock Squeak 4.2 image, which is as far as I can 
> >tell published as 6504.
> >
> >Now, I open and save it with the RoarVM, and then try to open it with 
> >Stack/CogVM, which crashes.
> I tried to dig into this a bit more.
> 
> The latest StackInterpreterSimulator in the image provided by Eliot on 
> the Cog branch seems to read the image [1] just fine.
> It seems to hang, but might also be that I am to inpatient.
> 
> Anyway, a debug build of 
> http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz loads 
> the image, too.
> 
> The available 5.x mac releases fail to load it: http://www.squeakvm.org/mac/
> 
> 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

This is in the initializeInterpreter function, and i3 would probably
be a local var or parameter from some method that got inlined into
that method. If in fact it is an overflow, that might be a symptom
of e.g. some uninitialized variable that allows a scan through object
memory to run amok.

This is quite possibly a red herring, inasmuch as the i3 variable
does not appear to have anything to do with the line of code that
crashed, but it does look odd, so you might want to look at the
initializeInterpreter() function in src/vm/gcc3x-cointerp.c and
see where it is coming from.

I don't know if I'm looking at the same version of the oscog VMMaker
that you are using, but the i3 variable that I get is here:

        /* begin flushMethodCache */
        for (i3 = 1; i3 <= MethodCacheSize; i3 += 1) {
                GIV(methodCache)[i3] = 0;
        }

...which looks perfectly innocent to me, so again, maybe just a
red herring. But any time I see a negative sqInt in the context
of scanning object memory, it catches my attention.

Dave