On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko siguctua@gmail.com wrote:
we should reafctor the code for changing the method's trailer (source pointer) to avoid using #become: at all. this won't deal with VM bug per se, but at least prevent it from triggering.
No, that makes little sense. Instead provide me with a reproducible case and I'll fix it quickly. I fixed the case form last week in one day. Become: should work, but I can't fix things if I can't reproduce the bugs. So please take the time to produce an image that crashes from start-up.
On 25 February 2013 23:26, Esteban Lorenzano estebanlm@gmail.com wrote:
he is talking about some chrashes that happens fast, when you do become
:)
nothing about "fast become"
On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck <
marianopeck@gmail.com>
wrote:
mmm what do you mean by "fast becomeForward:" ?
On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni camillobruni@gmail.com wrote:
While setting up the new multi platform VM tests I saw that the tests
fail
extremely quickly when there are not PharoV10.sources available.
It is still our know #becomeForward: but on CompiledMethods, but I just want to share that.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
On 26 February 2013 19:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko siguctua@gmail.com wrote:
we should reafctor the code for changing the method's trailer (source pointer) to avoid using #become: at all. this won't deal with VM bug per se, but at least prevent it from triggering.
No, that makes little sense. Instead provide me with a reproducible case and I'll fix it quickly. I fixed the case form last week in one day. Become: should work, but I can't fix things if I can't reproduce the bugs. So please take the time to produce an image that crashes from start-up.
well, i didn't said that we should not look for a way how to ditch that issue. but we have little problem with it: it is very hard to reproduce.
look from another angle: if things will get stable by not using become, then: a) we can release new version of pharo earlier b) it narrows down the field of search for bug
but sure thing, i am with you, and even more.. for things like that we should find a way to write a deterministic test case which fails / crashes on old VMs and works on fixed ones.. because without such tests, it leaves a lot of uncertainty, like: did your latest fixes to become actually fixed anything? or they introduced yet another regression?
On 25 February 2013 23:26, Esteban Lorenzano estebanlm@gmail.com wrote:
he is talking about some chrashes that happens fast, when you do become :)
nothing about "fast become"
On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:
mmm what do you mean by "fast becomeForward:" ?
On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni camillobruni@gmail.com wrote:
While setting up the new multi platform VM tests I saw that the tests fail extremely quickly when there are not PharoV10.sources available.
It is still our know #becomeForward: but on CompiledMethods, but I just want to share that.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- best, Eliot
On Wed, Feb 27, 2013 at 8:47 AM, Igor Stasenko siguctua@gmail.com wrote:
On 26 February 2013 19:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko siguctua@gmail.com
wrote:
we should reafctor the code for changing the method's trailer (source pointer) to avoid using #become: at all. this won't deal with VM bug per se, but at least prevent it from
triggering.
No, that makes little sense. Instead provide me with a reproducible
case and I'll fix it quickly. I fixed the case form last week in one day. Become: should work, but I can't fix things if I can't reproduce the bugs. So please take the time to produce an image that crashes from start-up.
well, i didn't said that we should not look for a way how to ditch that issue. but we have little problem with it: it is very hard to reproduce.
look from another angle: if things will get stable by not using become, then: a) we can release new version of pharo earlier b) it narrows down the field of search for bug
but sure thing, i am with you, and even more.. for things like that we should find a way to write a deterministic test case which fails / crashes on old VMs and works on fixed ones.. because without such tests, it leaves a lot of uncertainty, like: did your latest fixes to become actually fixed anything? or they introduced yet another regression?
Here's the way I try to reproduce bugs. Once I have a doit that reproduces the case I prefix it with Smalltalk saveAs: 'crash', copy the new crash.changes file to crash.changes.save, and run the doit.
Then I overwrite the changes file with the copy, cp crash.changes.save crash.changes to get a consistent starting point, and run crash.image.
For example, yesterday Bert Freudenberg found a VM crash loading a particular update fo the compiler (turns out not to be a VM bug). The updateListFor: method was modified to reject newer updates than the one that caused the crash. Then I executed
Smalltalk saveAs: 'crash'. Utilities updateFromServer
and got a consistently reproducible case.
Now one can run the debug or assert VMs against the crash to debug. In my experience trying to understand complex VM bugs in cases where one tries to interact with the image using the mouse and keyboard is often fruitless.
On 25 February 2013 23:26, Esteban Lorenzano estebanlm@gmail.com
wrote:
he is talking about some chrashes that happens fast, when you do
become :)
nothing about "fast become"
On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck <
marianopeck@gmail.com>
wrote:
mmm what do you mean by "fast becomeForward:" ?
On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni <
camillobruni@gmail.com>
wrote:
While setting up the new multi platform VM tests I saw that the
tests fail
extremely quickly when there are not PharoV10.sources available.
It is still our know #becomeForward: but on CompiledMethods, but I
just
want to share that.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- best, Eliot
-- Best regards, Igor Stasenko.
Hi Eliot,
I have a very reproducible case :)
just take latest pharo 2.0 image, edit #condenseSources to remove:
VirtualMachine isRunningCogit ifTrue: [ self error: 'Sources cannot be condensed in a Cog (JIT enabled) Virtual Machine. Try a Stack VM.' ].
(so it runs it in cog :)
and execute
Smalltalk condenseSources.
BOOM! :)
and printAllStacks show that it stopped in #becomeForward:
Esteban
On Feb 26, 2013, at 7:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko siguctua@gmail.com wrote: we should reafctor the code for changing the method's trailer (source pointer) to avoid using #become: at all. this won't deal with VM bug per se, but at least prevent it from triggering.
No, that makes little sense. Instead provide me with a reproducible case and I'll fix it quickly. I fixed the case form last week in one day. Become: should work, but I can't fix things if I can't reproduce the bugs. So please take the time to produce an image that crashes from start-up.
On 25 February 2013 23:26, Esteban Lorenzano estebanlm@gmail.com wrote:
he is talking about some chrashes that happens fast, when you do become :)
nothing about "fast become"
On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:
mmm what do you mean by "fast becomeForward:" ?
On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni camillobruni@gmail.com wrote:
While setting up the new multi platform VM tests I saw that the tests fail extremely quickly when there are not PharoV10.sources available.
It is still our know #becomeForward: but on CompiledMethods, but I just want to share that.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- best, Eliot
Hi Eliot,
I have yet another case (but this is more complicated to reproduce and not sure if related to #becomeForward:)
take a pharo 2.0 and execute this:
go := Gofer new renggli: 'petit'. (go allResolved select: [ :each | each name beginsWith: 'Configuration' ]) do: [:each | self crLog: each packageName. go package: each packageName. Transcript show: each printString ; cr. go fetch.].
It takes much more time than the condenseSources example to show something but it will crash sometimes and it will freeze someothers.
cheers, Esteban
On Feb 28, 2013, at 2:44 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi Eliot,
I have a very reproducible case :)
just take latest pharo 2.0 image, edit #condenseSources to remove:
VirtualMachine isRunningCogit ifTrue: [ self error: 'Sources cannot be condensed in a Cog (JIT enabled) Virtual Machine. Try a Stack VM.' ].
(so it runs it in cog :)
and execute
Smalltalk condenseSources.
BOOM! :)
and printAllStacks show that it stopped in #becomeForward:
Esteban
On Feb 26, 2013, at 7:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko siguctua@gmail.com wrote: we should reafctor the code for changing the method's trailer (source pointer) to avoid using #become: at all. this won't deal with VM bug per se, but at least prevent it from triggering.
No, that makes little sense. Instead provide me with a reproducible case and I'll fix it quickly. I fixed the case form last week in one day. Become: should work, but I can't fix things if I can't reproduce the bugs. So please take the time to produce an image that crashes from start-up.
On 25 February 2013 23:26, Esteban Lorenzano estebanlm@gmail.com wrote:
he is talking about some chrashes that happens fast, when you do become :)
nothing about "fast become"
On Feb 25, 2013, at 10:26 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:
mmm what do you mean by "fast becomeForward:" ?
On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni camillobruni@gmail.com wrote:
While setting up the new multi platform VM tests I saw that the tests fail extremely quickly when there are not PharoV10.sources available.
It is still our know #becomeForward: but on CompiledMethods, but I just want to share that.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- best, Eliot
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Esteban Lorenzano -
Igor Stasenko