[Pharo-dev] [Vm-dev] Pharo VM bug 11130

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Apr 7 06:47:55 EDT 2014


2014-04-07 8:13 GMT+02:00 Pharo4Stef <pharo4Stef at free.fr>:

>
> On 06 Apr 2014, at 23:08, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>
> 2014-04-06 22:29 GMT+02:00 Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
>
>> Good news,
>> I've managed to make your issue apparently vanish in Pharo3.0 VM.
>> For this, I:
>> - cleaned up unecessary differences with Eliot's VMMaker.oscog branch,
>> - removed unecessary changes ahead of VMMaker.oscog-eem.333 version
>> (those stamped LucFabresse)
>> - carefully applied changes from VMMaker.oscog-eem.333 that were not
>> applied
>>   Note that this version was marked as merged, which it was obviously not
>>   Please, if you do not fully merge, but just cherry pick some changes,
>> it's better to not merge.
>> - upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu
>> - integrated the issues for which I emitted a pull request
>>
>> All this work can be found publicly at
>> https://github.com/nicolas-cellier-aka-nice/pharo-vm/compare/fixMergeWithEliotVersion333
>>
>> I cannot tell which missing change exactly was the root cause, and I
>> cannot dissect either, but I saw several + LiteralStart missing... Or it
>> could be related to cogit method/block native code generation...
>> The changes are most probably here
>>
>> https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d15c0b362123e3a77c8b6fd2e8
>>
>> Bad news,
>> the structures at beginning of src/cm/cogit.c are generated out of order,
>> and I didn't find the cause yet.
>> Once solved, I think my branch should be carefully reviewed and
>> integrated.
>>
>>
> Haha! this is Class class>>superclassOrder: which break things...
> The order of structures passed on input was mostly good but ruined on
> output...
>
> The Squeak ChangeSet class>>superclassOrder: does not convert the list of
> classes asSet, thus somehow preserves provided order.
> The Pharo version does not take so much care it seems...
> Apparently the method was changed again in Pharo3.0, but neither does it
> preserve order.
>
>
> Can you publish the change for the superclassOrder: as a bug entry?
> we should add a test
>
>
Yes, I did:
https://pharo.fogbugz.com/f/cases/13180/Class-class-superclassOrder-should-preserve-classes-order

Of course, those kind of expectations should be asserted by a test (I
didn't).


> After fixing it, compilation went well...
>
>
>>
>> 2014-04-03 4:13 GMT+02:00 Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com>:
>>
>>
>>>
>>>
>>> 2014-04-02 23:59 GMT+02:00 Stephan Eggermont <stephan at stack.nl>:
>>>
>>>
>>>> Nicolas wrote:
>>>> >Hmm, don't waste too much time.
>>>> >All these methods are unchanged in github pharo-vm head revision
>>>> (VMMaker-oscog-StefanMarr.313)
>>>> >The cause must be completely different in latest pharo vms.
>>>>
>>>> Uhm, why? They haven't changed.
>>>>
>>>
>>> Sorry, haven't changed means that there's no diff with the corrected
>>> version.
>>> IOW, the fixes from Eliot have been integrated for a long time already.
>>> You are seeing another symptom, probably another bug impacting the same
>>> code.
>>> There are many diffs between pharo's and Eliot's branch, but not where
>>> you're looking at.
>>>
>>>  Pharo vms 105 and later no longer crash, but all reliably show the bug.
>>>> And 236 is the last Squeak one to show the problem.
>>>>
>>>> I might take a look at Esteban's versions from the same time,
>>>> 228 and 229
>>>>
>>>> Stephan
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140407/d888af32/attachment-0002.html>


More information about the Pharo-dev mailing list