Re: [Vm-dev] Image crashing on startup, apparently during GC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Stephane Ducasse-3
> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

tesonep@gmail.com
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 <[hidden email]> 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.
[hidden email]

crash.dmp (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

alistairgrant
Hi Pablo,

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

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

tesonep@gmail.com
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 <[hidden email]> wrote:
Hi Pablo,

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




--
Pablo Tesone.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Eliot Miranda-2
Hi Pablo,

On Sat, Mar 31, 2018 at 10:19 AM, [hidden email] <[hidden email]> 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 <[hidden email]>
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 <[hidden email]> wrote:
Hi Pablo,

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




--
Pablo Tesone.
[hidden email]



--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

alistairgrant
Hi Pablo & Eliot,

On 31 March 2018 at 20:49, Eliot Miranda <[hidden email]> wrote:

> Hi Pablo,
>
> On Sat, Mar 31, 2018 at 10:19 AM, [hidden email] <[hidden email]>
> 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 <[hidden email]>
> 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. :-(.


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 <[hidden email]>
>> wrote:
>>>
>>> Hi Pablo,
>>>
>>> On 31 March 2018 at 18:36, [hidden email] <[hidden email]> 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
>>> > <[hidden email]>
>>> > 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.
>>> > [hidden email]
>>>
>>
>>
>>
>> --
>> Pablo Tesone.
>> [hidden email]
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

EstebanLM
hi,

On 31 Mar 2018, at 22:42, Alistair Grant <[hidden email]> wrote:

Hi Pablo & Eliot,

On 31 March 2018 at 20:49, Eliot Miranda <[hidden email]> wrote:
Hi Pablo,

On Sat, Mar 31, 2018 at 10:19 AM, [hidden email] <[hidden email]>
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 <[hidden email]>
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 <[hidden email]>
wrote:

Hi Pablo,

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




--
Pablo Tesone.
[hidden email]




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

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Aliaksei Syrel
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 <[hidden email]> wrote:
hi,

On 31 Mar 2018, at 22:42, Alistair Grant <[hidden email]> wrote:

Hi Pablo & Eliot,

On 31 March 2018 at 20:49, Eliot Miranda <[hidden email]> wrote:
Hi Pablo,

On Sat, Mar 31, 2018 at 10:19 AM, [hidden email] <[hidden email]>
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 <[hidden email]>
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 <[hidden email]>
wrote:

Hi Pablo,

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




--
Pablo Tesone.
[hidden email]




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


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Stephane Ducasse-3
In reply to this post by Stephane Ducasse-3
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Stephane Ducasse-3
In reply to this post by tesonep@gmail.com
Thanks Pablo for your time and willingness to help.

On Sat, Mar 31, 2018 at 6:36 PM, [hidden email] <[hidden email]> 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 <[hidden email]>
> 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.
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Stephane Ducasse-3
In reply to this post by Aliaksei Syrel
Good to know.

On Sun, Apr 1, 2018 at 12:52 PM, Aliaksei Syrel <[hidden email]> 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 <[hidden email]> wrote:
>>
>> hi,
>>
>> On 31 Mar 2018, at 22:42, Alistair Grant <[hidden email]> wrote:
>>
>> Hi Pablo & Eliot,
>>
>> On 31 March 2018 at 20:49, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi Pablo,
>>
>> On Sat, Mar 31, 2018 at 10:19 AM, [hidden email] <[hidden email]>
>> 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 <[hidden email]>
>> 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 <[hidden email]>
>> wrote:
>>
>>
>> Hi Pablo,
>>
>> On 31 March 2018 at 18:36, [hidden email] <[hidden email]> 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
>> <[hidden email]>
>> 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.
>> [hidden email]
>>
>>
>>
>>
>>
>> --
>> Pablo Tesone.
>> [hidden email]
>>
>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Image crashing on startup, apparently during GC

Eliot Miranda-2
In reply to this post by alistairgrant
Hi Alistair,

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

> On Mar 31, 2018, at 1:42 PM, Alistair Grant <[hidden email]> wrote:
>
> Hi Pablo & Eliot,
>
>> On 31 March 2018 at 20:49, Eliot Miranda <[hidden email]> wrote:
>> Hi Pablo,
>>
>> On Sat, Mar 31, 2018 at 10:19 AM, [hidden email] <[hidden email]>
>> 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.

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.

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.

>
>
>
>> As Alistair says, the issue is fixed in the VMMaker.oscog package commit
>> VMMaker.oscog-eem.2359, which is
>>
>> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
>> Author: Eliot Miranda <[hidden email]>
>> 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. :-(.
>
>
> 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 <[hidden email]>
>>> wrote:
>>>>
>>>> Hi Pablo,
>>>>
>>>>> On 31 March 2018 at 18:36, [hidden email] <[hidden email]> 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
>>>>> <[hidden email]>
>>>>> 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.
>>>>> [hidden email]
>>>>
>>>
>>>
>>>
>>> --
>>> Pablo Tesone.
>>> [hidden email]
>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>