[Vm-dev] Image crashing on startup, apparently during GC

[Alistair Grant]

On Sat, Mar 31, 2018 at 02:42:33PM +0200, Esteban Lorenzano wrote:
>  

> Hi,
> 
> 
>     On 31 Mar 2018, at 11:45, Alistair Grant <akgrant0710 at gmail.com> wrote:
> 
> 
>     On 23 March 2018 at 21:52, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 
>         Pharo urgently needs to upgrade the VM
> 
> 
>     I couldn't agree more, and I know Esteban wants to release a new VM.
>     I did quite a bit of testing on a VM from 15 March that I thought
>     would make a good candidate before realising that the Mac VMs aren't
>     available.
> 
> 
> I will try to promote then the one of 15 march. We?ll see next week. 

There were a few builds on the 15th, the VMs I tested were:

http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201803160215-43a2f5c.zip
http://files.pharo.org/vm/pharo-spur32/linux/pharo-linux-i386threaded-201803160215-43a2f5c.zip



> but then, this is part of my observation: We cannot know which VMs are stable,
> and that?s because the *process* to make them stable is very ?human dependent?:
> We consider a version stable when it builds on CI and Eliot says is stable. But
> since Eliot does not use Pharo (not a critic, a reality), that may be not true
> for Pharo. And that?s actually what happens, Pharo crashes. 
> I tried to avoid a bit this problem with our fork and nightly builds that runs
> the pharo tests (to knew about problems as early as possible). But to be honest
> I didn?t have the time (and the will) to work on it recently, then pharo fork
> is in practice stalled. I will revive that eventually? but just when I find the
> time and the spirit to do it.
> 
> 
> 
>         to one more up to date than 2017 08 27 (in fact more up-to-date than
>         opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri
>         Jan 19 13:17:57 2018 -0800).  The bug that VMMaker.oscog-eem.2320 fixes
>         can result in image corruption in large images, and can occur (as it
>         has here) at start-up, causing one's work to be irretrievably lost.
> 
> 
>     Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are
>     triggered either by the automated test suite or the bootstrap process.
> 
> 
>     The blocks I can see at the moment are:
> 
>     - Multiple builds have failed with an internal compiler error on the
>     sista builds.
>     -- The earliest occurrence I could find was commit 1f0a7da, but it may
>     have been earlier.
>     - Even if the Mac builds show success in travis, they aren't making it
>     on to files.pharo.org.
> 
> 
> latest VM copied into files.pharo.org is 16/03. 
> we need to see what?s happening there.
> 
> 
>     -- I haven't ever worked with this code.
> 
>     Not directly related, but:
>     - Bintray hasn't been updated since 8 March 2018.
> 
> 
>     I think it could also be useful for files.pharo.org to have release
>     candidate links available, which would help people to focus testing on
>     a particular VM.  They would need to be manually maintained, but I
>     think the benefits would be worthwhile.
> 
> 
> all VMs are available to test.
> just? not available *directly* to general users. 
> now? I could have a 70rc link in vm subdir. But since I cannot know which VM is
> RC I find it pointless at this moment.

I didn't mean that we would always be looking to release a new version,
but there have been multiple occassions in the past when you've asked
people to try a particular VM to see if it solves a problem.  In those
instances, marking it as RC would make it simpler for others to
contribute to the testing and give you more confidence to promote it to
stable.

Actually, if the link existed all the time, but most of the time it was
the same as the stable version, I'd probably just use it as my download
link, which would mean that I'm testing the RC whenever it comes out,
and stay with it while it is stable and there isn't a new RC.


Cheers,
Alistair