[squeak-dev] DictionaryIntegrityTest >> #testDictionaries failure
Levente Uzonyi
leves at elte.hu
Tue May 14 20:41:21 UTC 2013
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.
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
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
More information about the Squeak-dev
mailing list
|