> 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
