Hi guys,
I define a classInstVars: called 'Instances' to keep track of new persistent instances in my class FaBackgroundProcess. Of course, I implement #new to add those there. But I am having a very strange issue now. I have this accessor: FaBackgroundProccess class >> instances ^ Instances ifNil: [ Instances := OrderedCollection new ] If I execute: FaBackgroundProcess instances ->>>>> anOrderedCollection( ) I get an empty collection (which is what I expect). However, if I inspect the class FaBackgroundProcess and see the slot for 'Instances' I see lots of instances of FaBackgroundProcess! (when I expect to see same as the answer of #instances, that is, empty) And those instances are really alive as they prevent GC of other objects. So...what is going on???? I attach an screenshot with all the pieces. Any help is really welcome since I am lost. Thanks in advance, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass Screen Shot 2015-08-25 at 5.02.48 PM.png (432K) Download Attachment |
On Tue, Aug 25, 2015 at 5:25 PM, Jon Paynter <[hidden email]> wrote:
Hi Jon, I was thinking the same. I don't have a strong point. But in Pharo, for this type of instVar for tracking instances, I usually used a Class Instance Variable rather than Class Variable and never had an issue. Technically yes, I could use a class var instead. Even if I could use a class var in this case, aren't Class Instance Variables not working properly in GemStone? Or I am doing something wrong? Just to know for the future. BTW I forgot to said that classHistory size was 1. Thanks in advance,
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Mariano,
That is indeed odd behavior ... I would be suspicious of multiple versions of the class ... take a look at the oop of the class that you are sending the message to and the oop of the class you are inspecting ... Other than that I can't imagine the cause ... one step at a time though:) Dale On 08/25/2015 01:03 PM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi,
Why do you use classInstVars in Uppercase ? Regards, Bruno |
Administrator
|
In reply to this post by GLASS mailing list
Mariano, one possibility comes to mind. I'm not sure how you could have created the scenario, but it may be worth checking. See if you have a global definition of Instances somewhere other than the class variable. If the method was compiled with a reference to an association in UserGlobals, for example, you might be playing with two different associations. Browse the reference paths to the two collections.
|
In reply to this post by GLASS mailing list
Mmmmmm let me explain something else... I the instances of FaBackgroundProcess I used to hold the exception occurred (GsProcess). Such a GsProcess (part of the stack) was pointing to the class FaBackgroundProcess. I just inspected FaBackgroundProcess, inspect the 'Instances' , I got the collection, and I nil'ed the 'exception' instVar from each instance. Therefore, there was no more instance to THAT FaBackgroundProcess class. Now, either if I inspect FaBackgroundProcess OR send #intances now I see all empty and both being same OOP. So..what was going on for some reason is that the 'exception' stored in the FaBackgroundProcess instances were referencing ANOTHER instance of the class FaBackgroundProcess. Some days ago I added a instVar to FaBackgroundProcess and I did the typical #doBulkMigate since I didn't need anything special for this new instVar. So...could something with the migration make the already existing instances of FaBackgroundProcess point to another class? This all would make sense if classHistory size would have answered me something > 1, but it was still saying 1. so the problem is solved, but it would be nice if I could find an explanation. Thanks for you help guys. On Tue, Aug 25, 2015 at 5:33 PM, Dale Henrichs via Glass <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |