Hi Pablo, On 31 March 2018 at 18:36, [email protected] <[email protected]> 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 <[email protected]> > 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. > [email protected]
