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 <[email protected]> wrote: > >> On Jan 30, 2017, at 3:57 PM, Alexandre Bergel <[email protected]> >> 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
