[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