[Pharo-project] Help: #pointersTo broken (and fix, but I don't understand why it fixes)
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:) 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
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
Moreover, Squeak does anObj isInMemory ifTrue: [((anObj instVarsInclude: self) or: [anObj class == self]) ifTrue: [pointers add: anObj]]. anObj := anObj nextObject]. and it works fine. grrrrr On Thu, Dec 29, 2011 at 11:11 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
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
-- Mariano http://marianopeck.wordpress.com
Hi Mariano, just a tangent for now... On Thu, Dec 29, 2011 at 2:02 PM, Mariano Martinez Peck < marianopeck@gmail.com> 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.
primitiveObjectPointsTo is primitive number 132. primitiveVMPath is primitive 142 primitive numbers 146 & 147 are AFAICT unused.
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:)
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?
Write a test case and I'll take a look.
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
participants (3)
-
Eliot Miranda -
Mariano Martinez Peck -
Stéphane Ducasse