thierry we have pointersTo and I imagine that it is not good enough. Do you confirm? Stef On Tue, 31 Jan 2017 10:00:39 +0100, Thierry Goubier <thierry.goubier@gmail.com> wrote:
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
-- Using Opera's mail client: http://www.opera.com/mail/