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.goub...@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 <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
--
Using Opera's mail client: http://www.opera.com/mail/
