On Tue, May 10, 2011 at 10:59 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 10 May 2011 09:48, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
>
>
> On Tue, May 10, 2011 at 9:41 AM, Marcus Denker <marcus.denker@inria.fr>
> wrote:
>>
>> On May 10, 2011, at 9:32 AM, Mariano Martinez Peck wrote:
>>
>> >
>> > what is even worst, is that even after removing those correct CM, and
>> > doing a GC etc...they still don't disappear.
>> >
>>
>> There is
>>
>> � � � �ScriptLoader new cleanUpMethods
>>
>> This is called from #cleanUpForRelease and normally should make sure there
>> are no old methods.
>>
>
>
> hehehehe if I do: ScriptLoader new cleanUpForRelease, then inspect
> ((CompiledMethod allInstances select:� [:each | each trailer kind =
> #VarLengthSourcePointer] ) )
>
> they are not GC'ed and if then I click on the first element in the
> inspector.... VM CRASH!!!� with both, InterpreterVM and CogVM.
>
> :(
>

okay. it seems i found the offender. Its a CompiledMethod class>>cleanUp.
It changing a source pointer of all non-installed methods to 0.

Good catch!!!� :)�� Anyway, why CompiledMethod class >>cleanUp would like to destroy source pointers???
If I understood correctly (please correct me), all compiled methods will loose the pointer to sources and hence they will be decompiled after when they are ask their source!

I must be wrong, because the dev image when it is build, it calls all cleanUp methods for classes, so CompiledMethod class >> cleanUp shuld have been called, but if I take the Pharo1.3 result, I can see the source code (not decompiled)

When i do this, my image hangs.

I have just tried and it crash!!!� Actually, I evaluated CompiledMethod cleanUp. And just after cmd+b in CompiledMethod (to browse it) -> crash
How it is possilbe it didn't crash while building the dev image?�� or the first time I browse a class?
maybe this incorrect CM are created by the build process just after the cleanUp ?

Now i thinking that it should actually use empty trailer for those
methods i.e. CompiledMethodTrailer empty..�

Still i found it strange why some methods has broken bytecode.

Yes!! and why they are not GCed!!�

My theory is that some nasty code somewhere copied a compiled methods
using some unsafe technique, like:

1 to: oldMethod size do: [ :i | newMethod at: i put: (oldMethod at: i) ]

I will search to see if I find something.
The thing is that it is reproducible. Each new dev image build from scratch in a core, has these guys.

Because when you constructing compiled method normally (by compiling
them) , there is no way how you can get broken compiled methods. (we
would discover it much much earlier,

yes, exactly.
and in fact CompiledMethodTrailers are working for more than a year in
both pharo and squeak, and there was no any issues like this from
their side).


+1

--
Best regards,
Igor Stasenko AKA sig.




--
Mariano
http://marianopeck.wordpress.com