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,Thierry2017-01-31 5:00 GMT+01:00 John Brant <brant@refactoryworkers.com>:> 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