The Decompiler definitely has bugs. We disabled its tests because it needs quite a lot of work post closure integration.
Do you know what is referencing these compiled methods? i.e can they possibly be run. Or is it just a question of clean up? thanks, Mike On Sun, Nov 15, 2009 at 6:30 PM, Nicolas Cellier <[email protected]> wrote: > 2009/11/15 Hernán Morales Durand <[email protected]>: >> Hi Nicolas, >> Thanks for your comments. I've checked all CompiledMethods in a Core image >> >> | col | >> col := OrderedCollection new: 20. >> CompiledMethod allInstancesDo: [: cm | >> [ RBParser >> parseMethod: cm getSource asString >> onError: [ :msg :pos | col add: (msg -> cm) ] ] >> on: Error do: [: ex | ] ]. >> col explore >> >> which gave me 9 instances with problems, 8 of them have source pointer >> problems and they are uninstalled, in explorer : >> >> self collect: [: assoc | assoc value getSource asString ] >> > > I recommend trying: > ScriptLoader new cleanUpMethods. > That should eliminate most copies of CompiledMethod and replace with > an original. > > >> After applying your patch and condensing changes and source files, >> I've tried again >> >> CompiledMethod allInstances first getSource asString >> >> and the Decompiler raises now an exception, is this expected? >> It would be too hard to correct the source pointer numbers of >> uninstalled compiled methods? >> >> Cheers, >> >> Hernán >> > > Decompiler might have bugs, some since closure refactorings, some > older, but at least we know something is wrong. > I always prefer a Debugger to a false response ! > > Instead of simply erasing the source pointer of un-installed > CompiledMethod during condenseChanges/condenseSources, we could log > their source. > But it was already too late when I discovered this (while chasing > MethodProperties)... > >> 2009/11/15 Nicolas Cellier <[email protected]>: >>> You should check this: >>> CompiledMethod allInstances first isInstalled. >>> >>> If false, the answer probably is at >>> http://code.google.com/p/pharo/issues/detail?id=1423 >>> >>> 2009/11/15 Hernán Morales Durand <[email protected]>: >>>> Hi all, >>>> Possibly this is a bug. To reproduce it download a Pharo-Core (I'm >>>> using #11045), update from servers and evaluate: >>>> >>>> CompiledMethod allInstances first getSource asString >>>> >>>> if you see something like the following result, some things could be wrong: >>>> >>>> '(firstCollection at: index) equals: a. >>>> self assert: (secondCollection at: index) equals: b.] >>>> >>>> ' >>>> >>>> because that isn't a message pattern. The compiled method instance is >>>> >>>> (BlockClosure>>#newProcess "a CompiledMethod(1962)") >>>> >>>> and the source string is in PharoV10.sources, but >>>> #fileIndexFromSourcePointer: is answering "2" which is the changes >>>> file and should answer "1"... someone with a better understanding of >>>> sources arithmetic may comment. >>>> Cheers, >>>> >>>> Hernán >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
