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 <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