On Sat, 9 Jan 2010, K. K. Subramaniam wrote:
> Hi,
>
> I got a MNU: sendsToSuper in CodeHolder>>inheritanceButtonColor while browsing
> methods (log attached).
>
> currentCompiledMethod was nil this method. The initial test reads:
> ((currentCompiledMethod isKindOf: CompiledMethod) and: [Preferences
> decorateBrowserButtons]) ifFalse: [ ^Color transparent ].
>
> I presume currentCompiledMethod can be nil when this method is called. So I
> changed the test to:
> (Preferences decorateBrowserButtons
> or: [currentCompiledMethod isKindOf: CompiledMethod])
> ifFalse: [ ^ Color transparent ].
> to make it more robust.
>
> Is this the right fix? .. Subbu
>
No it's not, that would make the test weaker instead of more robust, since
if Preferences >> #decorateBrowserButtons returns true (which is the default
behavior) the other check is simply bypassed and the execution continues
without returning Color transparent.
Fixing this issue won't be easy, because it's a concurreny issue. The
execution normally never reaches the #sendsToSuper send, the method should
return after the first line. But the code passes the first line,
because currentCompiledMethod's value is not nil. Later at some other place
currentCompiledMethod's value is changed to nil, but this happens before
the code reaches the #sendsToSuper send. I guess MessageSet >>
#selectedMessage replaces the value of currentCompiledMethod when it
reaches this line:
currentCompiledMethod := class compiledMethodAt: selector ifAbsent: [nil].
So this problem should be fixed in another way.
Levente