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