Most CompiledMethod are registered in a methodDictionary. But some are not. (CompiledMethod allInstances reject: [:e | e methodClass ~~ nil and: [e selector ~~ nil and: [e == (e methodClass methodDictionary at: e selector ifAbsent: [nil])]]]) size This is often because a BlockClosure has been registered somewhere in a registry (a ServiceRegistry for example). The objects pointers chain is something like: a SeviceRegistry -> a ServiceAction -> a BlockClosure -> a MethodContext -> a CompiledMethod... Another source of MethodContext instances is a concurrent Process running in the image. If ever recompiled, a new instance of the CompiledMethod is installed in the methodDictionary. But the old CompiledMethod is still there, being pointed to by above chains. The old CompiledMethod has a source code pointer pointing to sourceCode somewhere in the change Log, and so far it's fine. But what if you compress the change log ? The registered CompiledMethod all get a valid new pointer to the new source location. But the unregistered ones retain their old pointer now pointing randomly in the change file. This is bad. (CompiledMethod allInstances select: [:e | e selector = #id:text:button:description:action: and: [(e methodClass methodDictionary at: e selector ifAbsent: [nil]) ~~ e]]) anyOne getSource Now if you try to decompile the method, either there is an Error like here, or unfortunately the random sourceCode is valid a valid chunk of Smalltalk and you open the door to potentially strange things... It could be misleading if you try to understand what the hell this SeviceAction could be doing. If you try to decompile the BlockClosure, and getSource does not point to valid code, it doesn't work, you get nil... This is another bug, because #decompile should revert to homeMethod decompile decompileString... I propose that #condenseChanges and the like, anihilate source code pointers of unregistered CompiledMethod. This should solve the issue. What do you think ?