Hi, I am taking the VM from the latest VM in http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo scripts, I believe is http://files.pharo.org/get-files/70/pharo-mac-latest.zip) The output of version in the VM is:
5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler: 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2347 uuid: 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid: 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Mar 15 20:36:43 2018 +0100 $ Plugins: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ I don't know if this information helps you to know the specific commit, but please feel free to tell me how I can get the exact commit from the VM. Or where to get other VMs to check the error. Cheers, Pablo On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0...@gmail.com> wrote: > Hi Pablo, > > On 31 March 2018 at 18:36, teso...@gmail.com <teso...@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.s...@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. > > teso...@gmail.com > > -- Pablo Tesone. teso...@gmail.com
