On Sep 28, 2007, at 11:26 AM, Joel VanderWerf wrote:

> That looks very useful. I'm not sure "leak" is the term I
> would use, since the objects are reachable. Unused reachable  
> objects can be just as much of a problem as unreachable objects, of  
> course.
>

agree.  we seem to be the minority though ;-(

> If you have Strings created in two places, are they reported  
> separately in the output? I assume so, but I couldn't tell from  
> your examples. If you're looking for trouble spots, it would be  
> useful to know not just that there were N strings floating around,  
> but that N1 of them were created on line L1, N2 on line L2, and so on.
>

yeah, that's *exactly* what it does.  of course some objects, like a  
= [], do not allow ruby hooks to track them so they just get reported  
under the general stacktrace of '[]', but at least they are reported.

> Does this have much of a cost on performance? (It doesn't use  
> trace_func, does it?) I'd like to have something like this enabled  
> by default for long-running deployed processes, not just in debugging.
>

not really.  it addes hooks into Object#initialize and Class#new to  
make sure the creation is stored via caller.  the location is stored  
in a big hash with finalizers to remove entries (object_id =>  
stacktrace of creation).  no reporting is done unless you call  
Dike.finger which, with the rails hooks, is done after every  
request.  so i wouldn't say it has now performance hit, but it should  
be a lowish hit.

i'd be very happy to get some feed back.  so far it's been very  
useful - i've been able to find several leaks in rails (i think)  
which i'm looking into now.  it found 5 leaks in my app and i was  
able to fix them easily in about 10 minutes, so that's nice.

cheers.

a @ http://drawohara.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama