Hi John, thanks for that tool. Have found a leak that I have been chasing like forever... I would vote to integrate that into the base image.
Regards, Thierry 2017-01-31 5:00 GMT+01:00 John Brant <br...@refactoryworkers.com>: > > On Jan 30, 2017, at 3:57 PM, Alexandre Bergel <alexandre.ber...@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 >
