[Vm-dev] Re: [Pharo-project] fast #becomeForward: crashes without PharoV10.sources

[Eliot Miranda]

On Wed, Feb 27, 2013 at 8:47 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 26 February 2013 19:20, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Tue, Feb 26, 2013 at 4:13 AM, Igor Stasenko <siguctua at 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 at 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 at gmail.com>
> >> > wrote:
> >> >
> >> > mmm what do you mean by "fast becomeForward:" ?
> >> >
> >> > On Mon, Feb 25, 2013 at 1:01 PM, Camillo Bruni <
> camillobruni at 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.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130227/d25d8c46/attachment.htm