Getters gone mad

59 views
Skip to first unread message

jtu...@objektfabrik.de

unread,
Jul 17, 2012, 2:46:21 PM7/17/12
to va-sma...@googlegroups.com
From time to time I have strange effects that go undiscovered for a while. And I seem to remember I've posted this to the old VAST Forum a few years ago.

So sometimes getters return the contents of a wrong instance variable. The source code looks good, and simply entering a blank character to the method and recompiling it heals the problem. I haven't been able to reproduce the problem reliably, but I suspect its has to do with the "Rename Variable As... with Accessors" refactoring. I haven't tried this time, but next time I'll try reloading the methods from envy into a new image to see if this is problem persists. Not sure what exactly that would tell me about my Refactoring theory. So far I haven't seen the same problem with setters... All I can tell is that in an inspector, the contents of an affected inst var is okay, but sending the sender returns the contents of another inst var. The getter of the other inst var is not necessarily returning the value of the affected inst var...

Has anybody seen this as well? This effect shows up every three or four months or so, so I'd say it's rare, but it is "interesting".

BTW: Is there an easy way to see what inst var a method refers to? Inspecting a CompiledMethod doesn't show (art least not in a way that jumps right at me) what I was looking for. Do I need to read the byte codes? If so, how can I do that (I know the Browsers were updated to show them, but  forgot how to load/activate that).

Joachim

Richard Sargent

unread,
Jul 17, 2012, 3:19:20 PM7/17/12
to va-sma...@googlegroups.com
Joachim,

I have seen a symptom like this. It took a while, but I was able to determine exactly what had gone wrong in our case. It may be your problem is from some other cause, however.

We discovered that if one were to load a different edition of the class definition from the changes browser, the existing compiled methods would not be recompiled to reflect the different instance variables and slots that the class change entailed.


I hope this is what is affecting you, as I would not want there to be a second cause of this!
       Richard

jtu...@objektfabrik.de

unread,
Jul 17, 2012, 3:51:05 PM7/17/12
to va-sma...@googlegroups.com
Richard,

I am glad I am not alone. 

Do you know if that was ever fixed or at least reported to IBM or Instantiations? Finding out what's wrong can be hard in such situations...

It is very well possible that I did something like "Load Alternatives" or such on a merge, but this specific project needs little merging because there aren't many developers involved. But I do refactor a lot, maybe that is why I suspect it is related to renaming accessors with variables...

Do you remember what you did to find out about the missing recompile? I figure this can take a lot of time... ;-)

Joachim

John O'Keefe

unread,
Jul 17, 2012, 4:07:48 PM7/17/12
to va-sma...@googlegroups.com
Joachim and Richard -

Not fixed (for sure) and not reported (as far as I can tell).

It would certainly help if we could get a reproducible scenario.

John

Richard Sargent

unread,
Jul 19, 2012, 9:02:45 AM7/19/12
to va-sma...@googlegroups.com
Unfortunately, John, I no longer remember exactly how to recreate the problem.  I just tried the obvious approach, but it works correctly, properly recompiling the methods when loading a changed class definition (in my example, I reverse the instance variables).
Reply all
Reply to author
Forward
0 new messages