Hi, I seem to be getting more of these errors recently. I'm on Mac Mojave 10.14.5, Pharo-7.0.3 64 bit, with the current stable vm (Mac OS X built on Jan 5 2019 19:11:02 ). Running the leak checker returns some leaks: (lldb) run --leakcheck 31 broken.image Process 3327 launched: '/Users/andrei/Documents/Pharo/images/pharo-vm/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) leak in free chunk 0x17221e8b8 @ 0 = 0x17521e888 is unmapped leak in free chunk 0x17421e890 @ 0 = 0x17a21e830 is unmapped leak in free chunk 0x17521e888 @ 0 = 0x18021e7d8 is unmapped leak in free chunk 0x17a21e830 @ 0 = 0x187d3e278 is unmapped Process 3327 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001230 Pharo`warning Pharo`warning: -> 0x100001230 <+0>: pushq %rbp 0x100001231 <+1>: movq %rsp, %rbp 0x100001234 <+4>: pushq %rbx 0x100001235 <+5>: pushq %rax Target 0: (Pharo) stopped. The when using `storePointerUncheckedofObjectwithValue` I seem to get an error: (lldb) call storePointerUncheckedofObjectwithValue(0,0x17221e8b8,nilObj) error: warning: got name from symbols: nilObj error: 'storePointerUncheckedofObjectwithValue' has unknown return type; cast the call to its declared return type Is this a problem with the way I compiled the assert vm? And is there a way to explore how the leaked objects get created? Cheers, Andrei On Fri, Mar 23, 2018 at 11:02 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Damien,

On Fri, Mar 23, 2018 at 1:52 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

Hi Damien,

On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <damien.pollet@gmail.com> wrote:

...

Here are the files (image and various outputs). Running with --leakcheck does mention a few object leaks (see output.txt);

Indeed the image is corrupt at start-up. See below.

...

I'm not sure where to get or how to build an assert VM.

When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app.

Note that if you build an Assert VM you will be able to manually patch the image in lldb so that you can rescue it. It looks like this:

$ lldb PharoAssert.app/Contents/MacOS/Pharo

(lldb) target create "/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo" Current executable set to '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64). (lldb) settings set -- target.run-args "clap_broken.d9e5daa.image" (lldb) b warning Breakpoint 1: 3 locations. (lldb) run --leakcheck 31 clap_broken.d9e5daa.image Process 31569 launched: '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) object leak in 0x10f919658 @ 0 = 0x122216538 object leak in 0x10fbb3448 @ 0 = 0x122216760 object leak in 0x10fbb3480 @ 0 = 0x1222166a8 object leak in 0x10ff384f0 @ 0 = 0x122d480b0 object leak in 0x10ff38518 @ 0 = 0x122d480b0 object leak in 0x10ff385d0 @ 0 = 0x122d480b0 Process 31569 stopped * thread #1: tid = 0x5b6d56, 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44 41 sqInt warnpid, erroronwarn; 42 void 43 warning(char *s) { /* Print an error message but don't necessarily exit. */ -> 44 if (erroronwarn) error(s); 45 if (warnpid) 46 printf("\n%s pid %ld\n", s, (long)warnpid); 47 else (lldb) call storePointerUncheckedofObjectwithValue(0,0x10f919658,nilObj) (sqInt) $0 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10fbb3448,nilObj) (sqInt) $1 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10fbb3480,nilObj) (sqInt) $2 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff384f0,nilObj) (sqInt) $3 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff38518,nilObj) (sqInt) $4 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff385d0,nilObj) (sqInt) $5 = 4478138592 (lldb) expr checkForLeaks = 0 (sqInt) $0 = 0 (lldb) c

and then save the image.

...

...

I also realized the VM I had was from this summer (the one that comes with a 70 image with zeroconf). The output files I include were produced by the VM at get.pharo.org/64/vmLatest70

https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0

On 20 March 2018 at 18:17, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

Hi Damien,

On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <damien.pollet@gmail.com> wrote:

...

Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?

Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information.

...

Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955)

Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320:

Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.

Pharo urgently needs to upgrade the VM 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.

...

...

...

Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501

Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE

Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154

Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY

VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1

Application Specific Information: abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804

-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

-- _,,,^..^,,,_ best, Eliot

-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

-- _,,,^..^,,,_ best, Eliot

-- _,,,^..^,,,_ best, Eliot

hi,

On 24 Mar 2018, at 09:50, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:

Le 23/03/2018 à 21:52, Eliot Miranda a écrit :

...

Hi Damien,

Indeed the image is corrupt at start-up. See below.

Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320:

Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.

Pharo urgently needs to upgrade the VM 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.

Hi Eliot,

I think that there is a lot of people who would like to get a newer stable vm for Pharo 6.1 and 7. The problem is that it is hard to know which VM are stable enough to be promoted as stable.

Some weeks ago Esteban tried to promote a VM as stable and he had to revert it the same day because a regression occurred in the VM.

If you're able to tell us which vms are stable in those present at http://files.pharo.org/vm/pharo-spur32/ and http://files.pharo.org/vm/pharo-spur64/ it would be a great help.

Even better would be for the pharo community to have a way to know which vms are stable or not without having to ask you.

there is no “stable” branch in Cog, and that’s a problem. “released” versions (the version you can find as stable) are not working for Pharo :( I tried to promote versions from end feb and that crashed. next week I will try again, maybe now they are stable enough… one thing is true: the versions that we consider stable (from oct/17) present problems that are already solved on latest. Esteban

Have a nice day.

...

-- _,,,^..^,,,_ best, Eliot

-- Cyril Ferlicot https://ferlicot.fr

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

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

Hi Pablo, On Sat, Mar 31, 2018 at 10:19 AM, tesonep@gmail.com <tesonep@gmail.com> wrote:

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.

The best one can do is either - running the VM executable from the command line using --version - via the System Reporter Alas git doesn't help here. Unlike many other scc systems git doesn't provide a metalanguage to embed the current commit id into source. The best we have is the time stamp and as we can see the granularity isn't good enough when things are changing quickly. As Alistair says, the issue is fixed in the VMMaker.oscog package commit VMMaker.oscog-eem.2359, which is commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb Author: Eliot Miranda <eliot.miranda@gmail.com> Date: Thu Mar 15 18:09:12 2018 -0700 CogVM source as per VMMaker.oscog-eem.2359 Cogits: Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so a guard is needed. I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog commit. I thought it did. I'll fix this.

Cheers, Pablo

On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710@gmail.com> wrote:

...

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

-- Pablo Tesone. tesonep@gmail.com

-- _,,,^..^,,,_ best, Eliot

hi,

On 31 Mar 2018, at 22:42, Alistair Grant <akgrant0710@gmail.com> wrote:

Hi Pablo & Eliot,

On 31 March 2018 at 20:49, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:

...

Hi Pablo,

On Sat, Mar 31, 2018 at 10:19 AM, tesonep@gmail.com <tesonep@gmail.com> wrote:

...

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.

The best one can do is either - running the VM executable from the command line using --version - via the System Reporter

Alas git doesn't help here. Unlike many other scc systems git doesn't provide a metalanguage to embed the current commit id into source. The best we have is the time stamp and as we can see the granularity isn't good enough when things are changing quickly.

git doesn't provide a substitution mechanism like sccs, but the script we have that embeds the date can just as easily embed the hash. In .git_filters/RevDateURL.smudge there's a line that retrieves the commit date from git:

$date = `git log --format=%ad -1`;

to get the (short) hash we can simply add:

$shorthash = `git log --format=%h -1`;

The string substitution can then proceed as for the date.

I think it would be worthwhile having both the date and hash in the --version info.

I'm happy to add this in and update the --version output if there's general agreement.

...

As Alistair says, the issue is fixed in the VMMaker.oscog package commit VMMaker.oscog-eem.2359, which is

commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb Author: Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> Date: Thu Mar 15 18:09:12 2018 -0700

Which unfortunately is 1 commit after the version you have.

There appears to be a separate problem that MacOS VMs aren't being uploaded to files.pharo.org <http://files.pharo.org/>, so while running the VM through the Pharo automated test suite and bootstrap process is a great idea, right now we need to wait for an updated VM for MacOS. :-(.

I just figured out last green build of Cog was 16 days ago so is correct (and not an error) that no mac build is being copied: there is no build since linux build failed and then no mac build was ran. Is not a problem about mac files copied to pharo file server but a general one (but that does not explains the bintray problem, since last upload there is from 8/03 and there was at least one successful build after) cheers, Esteban

Cheers, Alistair

...

CogVM source as per VMMaker.oscog-eem.2359

Cogits: Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so a guard is needed.

I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog commit. I thought it did. I'll fix this.

...

Cheers, Pablo

On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710@gmail.com> wrote:

...

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

-- Pablo Tesone. tesonep@gmail.com

-- _,,,^..^,,,_ best, Eliot

Good to know. On Sun, Apr 1, 2018 at 12:52 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

Hi,

Bintray has 6 months upload limit for the same release. Uploading of a new binary to #development release becomes impossible after 6 month since creation of that release. I have to delete and re-create releases once in a while...

Cheers, Alex

On 1 April 2018 at 12:49, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

hi,

On 31 Mar 2018, at 22:42, Alistair Grant <akgrant0710@gmail.com> wrote:

Hi Pablo & Eliot,

On 31 March 2018 at 20:49, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Pablo,

On Sat, Mar 31, 2018 at 10:19 AM, tesonep@gmail.com <tesonep@gmail.com> wrote:

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.

The best one can do is either - running the VM executable from the command line using --version - via the System Reporter

Alas git doesn't help here. Unlike many other scc systems git doesn't provide a metalanguage to embed the current commit id into source. The best we have is the time stamp and as we can see the granularity isn't good enough when things are changing quickly.

git doesn't provide a substitution mechanism like sccs, but the script we have that embeds the date can just as easily embed the hash. In .git_filters/RevDateURL.smudge there's a line that retrieves the commit date from git:

$date = `git log --format=%ad -1`;

to get the (short) hash we can simply add:

$shorthash = `git log --format=%h -1`;

The string substitution can then proceed as for the date.

I think it would be worthwhile having both the date and hash in the --version info.

I'm happy to add this in and update the --version output if there's general agreement.

As Alistair says, the issue is fixed in the VMMaker.oscog package commit VMMaker.oscog-eem.2359, which is

commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb Author: Eliot Miranda <eliot.miranda@gmail.com> Date: Thu Mar 15 18:09:12 2018 -0700

Which unfortunately is 1 commit after the version you have.

There appears to be a separate problem that MacOS VMs aren't being uploaded to files.pharo.org, so while running the VM through the Pharo automated test suite and bootstrap process is a great idea, right now we need to wait for an updated VM for MacOS. :-(.

I just figured out last green build of Cog was 16 days ago so is correct (and not an error) that no mac build is being copied: there is no build since linux build failed and then no mac build was ran. Is not a problem about mac files copied to pharo file server but a general one (but that does not explains the bintray problem, since last upload there is from 8/03 and there was at least one successful build after)

cheers, Esteban

Cheers, Alistair

CogVM source as per VMMaker.oscog-eem.2359

Cogits: Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so a guard is needed.

I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog commit. I thought it did. I'll fix this.

Cheers, Pablo

On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710@gmail.com> wrote:

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

-- Pablo Tesone. tesonep@gmail.com

-- _,,,^..^,,,_ best, Eliot

On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote:

Hi Alistair,

_,,,^..^,,,_ (phone)

...

On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710@gmail.com> wrote:

git doesn't provide a substitution mechanism like sccs, but the script we have that embeds the date can just as easily embed the hash. In .git_filters/RevDateURL.smudge there's a line that retrieves the commit date from git:

$date = `git log --format=%ad -1`;

to get the (short) hash we can simply add:

$shorthash = `git log --format=%h -1`;

The string substitution can then proceed as for the date.

I think it would be worthwhile having both the date and hash in the --version info.

I'm happy to add this in and update the --version output if there's general agreement.

Yes please!!! The conventional alternative is to invoke git log from the makefiles and lass in the commit hash as a compiler-line default me. But this is messy and slows down compilation (unless there is a special rule for just one file, and that's fragile). I much prefer having the commit somewhere in source.

Done: $ git log --oneline | head 5a5b1c7 vm version string: add commit short hash 4c4686e Skip SUnit testing in Sista builds 79c0809 Merge pull request #230 from smalltalking/Cog 804ed5c Fixed typo in the download URL $ products/cogspur64linuxht/pharo --version 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $ Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash [default: /home/alistair/vmmaker/opensmalltalk-vm/products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/] As expected, the hash is also included in: - the VirtualMachine object (in Pharo, and the equivalent in squeak) - crash.dmp - kill -USR1 output https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 if anyone wants to take a look.

If you do go ahead with this also consider modifying the makefiles to ensure that updateSCCSVersions has been run at least once before the bulk of the build is done.

I'll think about this separately. updateSCCSVersions is quite slow to execute on Windows in a VM, and I think there are other proposed changes waiting to be reviewed. Cheers, Alistair

Hi Ben, On 2 April 2018 at 15:42, Ben Coman <btc@openinworld.com> wrote:

On 2 April 2018 at 20:26, Alistair Grant <akgrant0710@gmail.com> wrote:

...

On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote:

...

Hi Alistair,

_,,,^..^,,,_ (phone)

...

On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710@gmail.com> wrote:

git doesn't provide a substitution mechanism like sccs, but the script we have that embeds the date can just as easily embed the hash. In .git_filters/RevDateURL.smudge there's a line that retrieves the commit date from git:

$date = `git log --format=%ad -1`;

to get the (short) hash we can simply add:

$shorthash = `git log --format=%h -1`;

The string substitution can then proceed as for the date.

I think it would be worthwhile having both the date and hash in the --version info.

I'm happy to add this in and update the --version output if there's general agreement.

Yes please!!! The conventional alternative is to invoke git log from the makefiles and lass in the commit hash as a compiler-line default me. But this is messy and slows down compilation (unless there is a special rule for just one file, and that's fragile). I much prefer having the commit somewhere in source.

Done:

$ git log --oneline | head 5a5b1c7 vm version string: add commit short hash 4c4686e Skip SUnit testing in Sista builds 79c0809 Merge pull request #230 from smalltalking/Cog 804ed5c Fixed typo in the download URL

$ products/cogspur64linuxht/pharo --version 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $

Maybe rather than just "Hash:" could it be more explicit as "GitHash:" or even "GitSHA1:" One day the algorithm is likely to change... "Moving Git past SHA-1" (https://lwn.net/Articles/715716/) and it may be useful later to be able to distinguish.

I like "GitHash" as it may not be obvious what the hash refers to for a newcomer. Even if/when git moves away from sha1, from a cli/ui perspective presumably it will still just be "the hash".

...

Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash [default: /home/alistair/vmmaker/opensmalltalk-vm/products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/]

As expected, the hash is also included in:

- the VirtualMachine object (in Pharo, and the equivalent in squeak)

I presume this is what shows up under System > System Reporter ?

Yes.

...

- crash.dmp - kill -USR1 output

https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 if anyone wants to take a look.

An interesting insight for me into how the version info is generated. thx.

Glad it was useful. :-) Thanks for your feedback. I'll update the PR (probably tomorrow). Cheers, Alistair

On 3 April 2018 at 01:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Alistair, Hi Ben,

...

On Apr 2, 2018, at 9:28 AM, Alistair Grant <akgrant0710@gmail.com> wrote:

Hi Ben,

...

On 2 April 2018 at 15:42, Ben Coman <btc@openinworld.com> wrote:

...

On 2 April 2018 at 20:26, Alistair Grant <akgrant0710@gmail.com> wrote:

...

On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote: Hi Alistair,

_,,,^..^,,,_ (phone)

...

On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710@gmail.com> wrote:

git doesn't provide a substitution mechanism like sccs, but the script we have that embeds the date can just as easily embed the hash. In .git_filters/RevDateURL.smudge there's a line that retrieves the commit date from git:

$date = `git log --format=%ad -1`;

to get the (short) hash we can simply add:

$shorthash = `git log --format=%h -1`;

The string substitution can then proceed as for the date.

I think it would be worthwhile having both the date and hash in the --version info.

I'm happy to add this in and update the --version output if there's general agreement.

Yes please!!! The conventional alternative is to invoke git log from the makefiles and lass in the commit hash as a compiler-line default me. But this is messy and slows down compilation (unless there is a special rule for just one file, and that's fragile). I much prefer having the commit somewhere in source.

Done:

$ git log --oneline | head 5a5b1c7 vm version string: add commit short hash 4c4686e Skip SUnit testing in Sista builds 79c0809 Merge pull request #230 from smalltalking/Cog 804ed5c Fixed typo in the download URL

$ products/cogspur64linuxht/pharo --version 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $

Maybe rather than just "Hash:" could it be more explicit as "GitHash:" or even "GitSHA1:" One day the algorithm is likely to change... "Moving Git past SHA-1" (https://lwn.net/Articles/715716/) and it may be useful later to be able to distinguish.

I like "GitHash" as it may not be obvious what the hash refers to for a newcomer. Even if/when git moves away from sha1, from a cli/ui perspective presumably it will still just be "the hash".

Commit Hash? Commit Hash (git)? C Commit Hash? Repository Commit Hash?

We've already moved from one sccs to another for the C code and may move again if anyone improves on git, which is not inconceivable.

Makes sense, CommitHash it is. I've updated the PR. But since Nicolas and Fabio are busy working on getting the build and deploy pipe-line working I'll wait a bit before merging rather than potentially derailing their work (thanks, guys!). Cheers, Alistair

...

...

...

Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash [default: /home/alistair/vmmaker/opensmalltalk-vm/products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/]

As expected, the hash is also included in:

- the VirtualMachine object (in Pharo, and the equivalent in squeak)

I presume this is what shows up under System > System Reporter ?

Yes.

...

...

- crash.dmp - kill -USR1 output

https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 if anyone wants to take a look.

An interesting insight for me into how the version info is generated. thx.

Glad it was useful. :-)

Thanks for your feedback. I'll update the PR (probably tomorrow).

Cheers, Alistair

Thanks Pablo for your time and willingness to help. On Sat, Mar 31, 2018 at 6:36 PM, 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.

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

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.

Yes this would be a good idea.