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

David T. Lewis lewis at mail.msen.com
Mon Jul 18 17:07:37 UTC 2011


On Mon, Jul 18, 2011 at 03:01:07PM +0200, 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
> >The difference between the 6505 format at 6504 format is the word
> >reversal for floats when running on little-endian. That is the only
> >difference in the image itself, but Cog/StackInterpreter also add
> >some additional information in the image file header. This means
> >that if you load a 6505 format image into RoarVM, and later save
> >it in that same format (as opposed to converting back to 6504),
> >then your image file header will be missing some information that
> >an actual Cog VM would expect to see.
> I should have left out the mentioning of 6505, sorry for the confusion.
> I do not think that it has anything to do with that.
> 
> 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.

Ah, I see. I suspect that one of the values that you write to the
image header when saving from RoarVM may be causing the problem. It
may be that the standard interpreter VM is more permissive than Cog
with respect to loading the image, so perhaps you are saving a value
(e.g. related to memory size) that causes a problem on Cog but not
on the standard interpreter. I am away and cannot look at it right
now, but reading your saved image with a StackInterpreterSimulator
might point to the problem.

HTH,
Dave



More information about the Vm-dev mailing list