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

Reply via email to