[squeak-dev] Re: UI lockup in Squeak 4.1
Chris Muller
asqueaker at gmail.com
Wed Jul 14 16:30:25 UTC 2010
I'm not sure if this is the same context of the issue you had, but..
this seems like a good time to reflect on #becomeForward:.
Until 5 or 6 years ago, we only had Object>>#becomeForward: (and not
#becomeForward:copyHash:). #becomeForward: would mutate the
identityHash of the argument to be that of the receiver, causing any
identity-hashed collections it might be residing in to need to be
rehashed.
Unfortunately, mutating the identityHash of important objects such as
an important Symbol in the SymbolTable (like, #at: !!); there was no
time to rehash the SymbolTable or anything else before the system
needed it, couldn't find it, and locked up.
So we added Object >> #becomeForward:copyHash: so that false could be
passed as the second argument, causing it not to mutate the
identityHash of the target.
- Chris
On Wed, Jul 14, 2010 at 3:31 AM, Rob Withers <reefedjib at yahoo.com> wrote:
> I found the problem!
>
> Of course, it was my code causing this. I was doing the equivalent of:
>
> Object new becomeForward: nil.
>
> and this was nilling out the contents of that KnownEnvironments dictionary.
> I tested with the above code, without my code, and indeed it caused the
> problem. I am now avoiding both SmallIntegers and nil when using
> #becomeForward:
>
> Thanks for everyone's help in this matter!
>
> Rob
> From: Eliot Miranda
> Sent: Tuesday, July 13, 2010 5:03 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1
>
>
> On Tue, Jul 13, 2010 at 1:53 PM, Rob Withers <reefedjib at yahoo.com> wrote:
>>
>>> From: Eliot Miranda
>>> Sent: Tuesday, July 13, 2010 4:11 PM
>>> To: The general-purpose Squeak developers list
>>> Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1
>>>
>>>
>>>
>>>
>>>
>>> > On Tue, Jul 13, 2010 at 12:59 PM, Rob Withers <reefedjib at yahoo.com> >
>>> > wrote:
>>> >
>>> > Hi Eliot,
>>> >
>>> >
>>> > I already found it.
>>> >
>>>
>>> Doh!
>>>
>>> > It is this method, when the result of the dictionary lookup is nil for
>>> > > 'en', and it recursively calls localeID: with 'en'.
>>> >
>>> >
>>> > LanguageEnvironment class>>#localeID: localeID
>>> > ^self knownEnvironments at: localeID ifAbsent: [self localeID:
>>> > (LocaleID
>>> > isoLanguage: 'en')]
>>> >
>>>
>>>
>>> which clearly needs to read something like
>>> LanguageEnvironment class>>#localeID: localeID
>>> ^self knownEnvironments
>>> at: localeID
>>> ifAbsent: [self knownEnvironments at: (LocaleID isoLanguage:
>>> 'en')]
>>>
>>
>> The problem is that something changed the entry for 'en' from
>> Latin1Environment to nil. So the absent block will still fail, although
>> this time as an Error and not a recursive, memory-growing loop.
>>
>> I had in mind:
>> LanguageEnvironment class>>#localeID: localeID
>>
>> ^self knownEnvironments
>> at: localeID
>> ifAbsent: [
>> | env id |
>> env := Latin1Environment new.
>> id := LocaleID isoString: 'en'.
>> env localeID: id.
>> self knownEnvironments at: id put: env.
>> ^ env].
>
>
> LanguageEnvironment class>>#localeID: localeID
> ^self knownEnvironments
> at: localeID
> ifAbsent: [self knownEnvironments
> at: (LocaleID isoLanguage: 'en')
> ifAbsentPut:
> [Latin1Environment new
> localeID: (LocaleID isoString: 'en');
> yourself]]
>
> No?
>>
>>
>>>
>>> > I start the image with an intact KnownEnvironments. Something somehow
>>> > > nils out the entries after I > > > have run for awhile. ??????
>>> >
>>>
>>> So guard against resetKnownEnvironments?
>>
>> I had a 'self halt' and it never got called.
>>
>> I have no idea how it was nilling out the entries.
>
> Are there any senders of knownEnvironments and removeKey: et al? Do you
> have changes to Dictionary grow code which causes a bug on rehash? etc...
>>
>> Rob
>>
>>
>>
>
> ________________________________
>
>
>
>
More information about the Squeak-dev
mailing list
|