some issues with latest standard VM

 
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 ''

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

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.

 
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).

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