Image crashing on startup, apparently during GC

> Hi Alistair,
>
> _,,,^..^,,,_ (phone)
>
> > On Mar 31, 2018, at 1:42 PM, Alistair Grant <[hidden email]> 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.

>
>
>
> On 2 April 2018 at 20:26, Alistair Grant <[hidden email]> 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 <[hidden email]> 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.

>> 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 ?

>> - 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.

> On Apr 2, 2018, at 9:28 AM, Alistair Grant <[hidden email]> wrote:
>
>
> Hi Ben,
>
>
>> On 2 April 2018 at 15:42, Ben Coman <[hidden email]> wrote:
>>
>>
>>
>>> On 2 April 2018 at 20:26, Alistair Grant <[hidden email]> 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 <[hidden email]> 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

>
> Hi Alistair, Hi Ben,
>
>
>> On Apr 2, 2018, at 9:28 AM, Alistair Grant <[hidden email]> wrote:
>>
>>
>> Hi Ben,
>>
>>
>>> On 2 April 2018 at 15:42, Ben Coman <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 2 April 2018 at 20:26, Alistair Grant <[hidden email]> 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 <[hidden email]> 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.

>>>> 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

>> 2018-04-03 10:27 GMT+02:00 Alistair Grant <[hidden email]>:
>>>
>>>
>>> On 3 April 2018 at 01:02, Eliot Miranda <[hidden email]> wrote:
>>> >
>>> > Hi Alistair, Hi Ben,
>>> >
>>> >
>>> >> On Apr 2, 2018, at 9:28 AM, Alistair Grant <[hidden email]> wrote:
>>> >>
>>> >>
>>> >> Hi Ben,
>>> >>
>>> >>
>>> >>> On 2 April 2018 at 15:42, Ben Coman <[hidden email]> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>>> On 2 April 2018 at 20:26, Alistair Grant <[hidden email]> 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 <[hidden email]> 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
>>
>>
>

>
>
> Hi Damien,
>
> On Fri, Mar 23, 2018 at 1:52 PM, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi Damien,
>>
>> On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>> Hi Damien,
>>>>
>>>> On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <[hidden email]> 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