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