Hi Pablo,

On 31 March 2018 at 18:36, tesonep@gmail.com <tesonep@gmail.com> wrote:
> Hi Everyone,
>�� ��I have created the PR in Pharo, so the CI runs the bootstrap with the
> latest VM (March 15th).
> Running the process fails during execution of the tests in 32bits OSX.
> It crashes the VM with a segmentation fault.
> I could reproduce the crash, running the tests from the command line, and
> also running OCBytecodeGeneratorTest test.


There were several VMs built on / around the 15th.�� Would you mind
letting me know the commit hash as Eliot fixed this particular problem
about then.

I tested 43a2f5c.

Thanks,
Alistair

>
> I am attaching the crash.dmp with both executions (from the commandLine and
> headful), both are in the same point.
>
> Cheers,
> Pablo
>
> On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse <stepharo.self@gmail.com>
> wrote:
>>
>> > I will try to promote then the one of 15 march. We���ll see next week.
>> > 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.
>>
>> Hi esteban
>>
>> What would be a way to fix the process and make your work easier?
>>
>> If you do not know what can be a release candidate then who can?
>> We should really improve this situation.
>>
>> Stef
>>
>>
>> > 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.
>> >
>> > cheers,
>> > Esteban
>> >
>> >
>> >
>> > Cheers,
>> > Alistair
>> >
>> >
>>
>
>
>
> --
> Pablo Tesone.
> tesonep@gmail.com