Hi John, Your tool is truly a gem! Yesterday I spent a couple of hours using #pointersTo to track some Roassal objects. But I was unsuccessful. Your tool help me immediately spot kept references. In particular, the following invocation frees all the Roassal and Athens surface objects: Clipboard startUp: true. GTPlayBook reset. RubEditingState allInstances do: [ :i | i undoManager reset. ]. CairoBackendCache soleInstance flush Should be included in the image. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jan 31, 2017, at 1:00 AM, John Brant <brant@refactoryworkers.com> wrote:
On Jan 30, 2017, at 3:57 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
The problem is still present. Looking at the pointers
There was an object reference crawler no? I remember someone worked on this? I tried sending #pointersTo but I without much success on identifying the cause of this leak.
Any idea?
I donât know if there is an existing object reference crawler, but I ported mine from VW. It finds the shortest paths so it is good for finding the reference that is causing the memory leak.
MCHttpRepository location: 'http://www.smalltalkhub.com/mc/JohnBrant/ReferenceFinder/main' user: '' password: ââ
Once loaded, you can evaluate something like "ReferenceFinder findPathToInstanceOf: MyClassâ. That will return a reference path or nil if no path exists from the Smalltalk global to an instance of MyClass. If you want to find a path to a particular instance, you can use âReferenceFinder findPathTo: myInstâ.
In the past, Iâve found that NECController and some compiler infrastructure (I forget the class) have been culprits for memory leaks with their caches.
John Brant