On 14 May 2013 21:41, Levente Uzonyi <leves at elte.hu> wrote:
> On Tue, 14 May 2013, Levente Uzonyi wrote:
>
>> On Tue, 14 May 2013, Frank Shearar wrote:
>>
>>> On 14 May 2013 12:28, Levente Uzonyi <leves at elte.hu> wrote:
>>>>
>>>> On Mon, 13 May 2013, Chris Muller wrote:
>>>>
>>>>> Usually this sort of problem is due to changing the hash key of an
>>>>> object in the dictionary -- but you said an IdentityDictionary so..
>>>>> unless there was a become: of some kind (with copyHash: false) then it
>>>>> may be something else..
>>>>
>>>>
>>>>
>>>> It's enough to change the key of the association to a different object.
>>>
>>>
>>> Which explains why it's something called #testClassRenamed causing the
>>> problem.
>>
>>
>> Well, it caused no problems before Environments, because the association
>> was removed from the SystemDictionary before renaming, and added again after
>> it.
>>
>> With Environments it's a bit more complicated, because there are two
>> dictionaries in an Environment: 'contents' and 'bindins'. I'm not sure what
>> the role of these are, but #renameClass:from:to: only removes the
>> association from 'contents'. If it's also present in 'bindings', then
>> 'bindings' will get into an invalid state.
>>
>> It's also a bit suspicious, that #associationAt: and
>> #associationAt:ifAbsent: both use 'contents' to get the association, but
>> #associationOrUndeclaredAt: uses 'bindings'.
>
>
> By chasing the pointers I found that some associations are stored in the
> Environment's exports variable's namespace variable. That is the
> IdentityDictionary which breaks during renaming, because it holds on the
> same association.

The test failure is also intermittent. Does that observation fit the hypothesis?

frank

> Levente
>
>
>>
>>
>> Levente
>>
>>>
>>> frank
>>>
>>>> Levente
>>>>
>>>>
>>>>>
>>>>> On Sun, May 12, 2013 at 6:30 AM, Frank Shearar
>>>>> <frank.shearar at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> This test fails because, as far as I can tell, SystemChangeFileTest >>
>>>>>> #testClassRenamed breaks the integrity of an IdentityDictionary.
>>>>>>
>>>>>> This IdentityDictionary (call it dict) reports having a key in
>>>>>> #keysAndValuesDo: such that dict at: key raises a KeyNotFound.
>>>>>>
>>>>>> Inspecting dict verifies this weirdness, even though you can see the
>>>>>> key in the inspector's right hand pane.
>>>>>>
>>>>>> Ideas?
>>>>>>
>>>>>> The diff in the manifests between the last version where this test
>>>>>> didn't fail and where it did looks like this:
>>>>>>
>>>>>> $ diff /home/frank/Downloads/TrunkImage.313.manifest
>>>>>> /home/frank/Downloads/TrunkImage.314.manifest
>>>>>> 22c22
>>>>>> < Monticello (bf.541)
>>>>>> ---
>>>>>>>
>>>>>>>
>>>>>>> Monticello (bf.542)
>>>>>>
>>>>>>
>>>>>> 26c26
>>>>>> < MorphicTests (ar.18)
>>>>>> ---
>>>>>>>
>>>>>>>
>>>>>>> MorphicTests (fbs.20)
>>>>>>
>>>>>>
>>>>>> 49c49
>>>>>> < Tests (fbs.207)
>>>>>> ---
>>>>>>>
>>>>>>>
>>>>>>> * Tests (fbs.212)
>>>>>>
>>>>>>
>>>>>> 62,63d61
>>>>>>
>>>>>> Not terribly enlightening...
>>>>>>
>>>>>> frank
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>