[Vm-dev] Re: Problem running Cuis with recent Cog VMs

[Phil (list)]

OK, this is getting strange.  Based on my previous post, I started
digging into why I might be seeing a bad changes file name and I have
no explanation for it.  But I can reproduce it, so I've uploaded an
image with a little debugging code to https://github.com/pbella/CogVM36
02Bug

With Cog VM 3427 (http://www.mirandabanda.org/files/Cog/VM/2015/VM.r342
7/) or older, the image starts up as expected and when started from a
terminal window I get:

imagePath: /tmp
imageName: /tmp/Cuis4.2-2679-debug.image
sources: nil
defaultSources: /tmp/CuisV4.sources
defaultChanges: /tmp/Cuis4.2-2679-debug.changes

Looks good.  So now I start it up with Cog 3602 (http://www.mirandaband
a.org/files/Cog/VM/VM.r3602/) and get:

imagePath: /tmp/Cuis4.2-2679-debug.im
imageName: /tmp/Cuis4.2-2679-debug.image
sources: nil
defaultSources: /tmp/Cuis4.2-2679-debug.imag/CuisV4.sources
alternativeSources: /home/Shared/Apps/coglinux-
16.07.3602/lib/squeak/4.5-3602/CuisV4.sources
defaultChanges: /tmp/Cuis4.2-2679-debug.image.changes

The image hangs the VM, but looking at the console output that's not
surprising (i.e. no valid sources or changes files.)  3602 appears to
run Squeak 5 without problems on my machine but the little I've traced
through its startup code, it does things differently which explains why
it's not having this issue.

Can someone try this on their machine to see if they can reproduce
these results with Cog 3602 and an older Cog VM? (based on building
from sources, the stack VM does not appear to have the problem)  Do you
get similar output?  Is this a problem on other platforms or just Linux
(x86)?

#openSourcesAndChanges (the browser in the image opens on this) and
loading Ken's StdIO package are the only changes from the base image.

Thanks,
Phil

On Mon, 2016-02-15 at 22:55 -0500, Phil (list) wrote:
> I've been doing a bit more digging into the problem I reported, and
> Douglas reproduced, with newer Cog VMs (the last VM that I have
> working
> at all is 3427 (though it has other issues), I can reproduce the
> crash
> with the latest repo source or the just release 3602).  While I
> haven't
> found a solution to it yet, it's looking very much like something
> changed in more recent VMs that is causing problems for FileMan.
> 
> What I've been able to determine so far is that when trying to start
> up, SystemDictionary>>openSourcesAndChanges is trying to open a
> changes
> file with the name <basename>.image.changes which of course fails.
>  When I override the exception handler to catch Exception rather than
> FileWriteError, the image hangs (empty/white windows, CPU utilization
> pegged... infinite loop somewhere I'd guess) rather than crashing.
>  So
> then I changed the exception handler to return 'emergency.changes'
> asFileEntry privateWriteStream rather than nil and we're back to
> crashing again.  In both cases, the crash appears to occur in
> #privateWriteStream call.  Each time I try to wrap the upstream code
> in
> logic that deals with the error, it gets a bit further before
> crashing... but that's just ignoring the issue rather than dealing
> with
> it.  It's slow going since I never get to an image with a functioning
> debugger but it sure looks like there's something in the VM that
> FileMan doesn't like... does this give anyone any ideas?  (on either
> side: what's killing FileMan or what changed in the VM)
> 
> Thanks,
> Phil