Help: #pointersTo broken (and fix, but I don't understand why it fixes)

On Dec 29, 2011, at 11:02 PM, Mariano Martinez Peck wrote:

> Hi guys. #pointersTo is broken and that's why some tests of PointerFinderTest are yellow. Few weeks ago, I changed  #pointsTo: so that it does not perform primitive 142 but it delegates to a new method #instVarsInclude: which has the primitive 132 now.
>
> Before this change, if I open a workspace and execute the following:
>
> | aDate |
> aDate := Date new.
> aDate pointersTo
>
> if you execute that several times, it is ALWAYS empty. After the change, in different executions answer not only empty but some MethodContext instances whose method is (ProtoObject>>#pointsTo: "a CompiledMethod(220463104)"). Most of the times, in these MethodContext instances, the receiver are the instance variables of aDate
> So #pointersTo answer, for example, an Array(CompiledMethod(ProtoObject)>>pointsTo: Time(ProtoObject)>>pointsTo: Duration(ProtoObject)>>pointsTo:)

I saw that too and I was confused.
Thanks for taking the time to look at it.
We often had a debugger open so I thought it was the reason.

>
> This causes #pointersToExcept:  to have a different behavior. If in #pointersToExcept:  I replace  #pointsTo:  with  #instVarsInclude:  it works perfect. The only difference is that one includes the class and the other one doesn't. BUT, in this example, the receiver is aDate, hence, there shouldn't be any object which class is #aDate. In fact, if I put a  "(anObj class == self) ifTrue: [ self halt. ]" it NEVER HALT. That makes sense. But I don't understand then why with #pointsTo: it doesnt work and with #instVarsInclude:  it works perfect.
>
> Any idea?
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>