[Vm-dev] some issues with latest standard VM

David T. Lewis lewis at mail.msen.com
Mon Oct 8 23:25:42 UTC 2012


On Mon, Oct 08, 2012 at 02:20:33PM -0500, Chris Muller wrote:
>  
> I can't seem to interrogate the squeak VM version from the
> command-line with the 4.10.2.2614 Unix VM.
> 
> $ squeak -version
> cannot find VM to run image 'squeak' with option ''

I think this is a bug in the /usr/bin/squeak script, which Ian has 
updated to attempt to locate a Cog VM or a VM for 64-bit images if
appropriate, otherwise default to an interpreter VM. Apparently if
you do not have a squeak.image file in your current directory when
you run "squeak -version" the script gets confused. I don't have a
fix for this, but if you are comfortable hacking shell scripts I'm
sure Ian would appreciate a patch.

> 
> When I start an image, I see what appear to be a couple of debugging
> messages in the console:
> 
> $ squeak myImage &
> $ CHECKING cogvm
> CHECKING squeakvm

Yes, apparently some leftover debugging output. Check first for cogvm
before running the squeakvm (interpreter VM).

> Finally, I've discovered after doing heavy work in an image in Cog --
> something maybe happens to it because, while I can still open it under
> Cog, I can't open it with the regular VM.
> 
> $ squeak myImage &
> $ CHECKING cogvm
> CHECKING squeakvm
> squeakvm: /home/piumarta/squeak/platforms/unix/vm/sqUnixMemory.c:177:
> uxGrowMemoryBy: Assertion `newDelta >= 0' failed.
> 
> This last error also occurs with the 2357 VM, so it's been around a
> while.  With a fresh image saving under Cog and opening under the 2614
> VM works fine -- it's only after having done a lot of work in the
> image that something happens to make the standard VM crash when trying
> to open it, even though it still opens fine under Cog 2585.

Well this is an interesting problem indeed. I have not seen this myself,
but my first thought would be that it may be related to the image file
header. Cog stores some additional information there that the interpreter
VM does not know or care about, and up to this point I have not seen
any problems with it. But it looks like you are getting a memory allocation
failure at image load time, so I'm guessing the information that Cog
would have previously stored in the image header might be relevant.

Can you say any more about how to reproduce this? Are you setting any
CG parameters that might have an effect?

Dave



More information about the Vm-dev mailing list