ara.t.howard
1/11/2008 4:59:00 PM
On Jan 11, 2008, at 9:35 AM, Wincent Colaiuta wrote:
> So how do you interpret these kinds of results with empty stack
> traces? So you know a bunch of String and Array objects are being
> created and aren't going to be collected, at least at the point where
> you called Dike.finger, but you don't know where they were created
> (admittedly, there are so many of them it probably wouldn't help you
> much to know that they were being created "all over the place").
dike does what it can to track the object lifecycle, but certain
things cannot be traced to a specific file:line. for instance
string = "literal"
array = [ :literal ]
does not trigger Class.new, Class.allocate, or Object#initialze to be
triggered (in ruby) and this is the main mechanism for dike to track
objects. dike tracks objects per class per stacktrace so it knows
about the Leak objects coming from file a.rb, line 42, for example.
so certain objects cannot be tracked. it's a good reason to prefer
Hash.new over {} though ;-) if they could be tracked it wouldn't be
an issue that they were 'all over the place' since the dike
commandline tool provides a way to compare one dump to the next,
showing only leaks in the output and ignoring those entries that are
not leaks.
in the end it's a limitation of dike. nonetheless, i've been able to
reduce memory leaks in many rails apps in 30 minutes of work using
dike.rb, so it is not without it's usefulness. also, note that even
a c instrumented object cycle tracker will fail to detect things like
void *leak(){ return malloc(42) }
in a c extension - all the tools have their limits. for ruby i think
starting with something like dike.rb, moving up to something like
bleakhouse, with it's custom ruby, and finally moving on to c only
tools is a logical process to follow.
another very important technique is, as much as possible, to use
binary search on your code you determine leaks: hack your code so the
back 50% of it doesn't run - test for the leak - then adjust up or
down based on what you find. this along can narrow down on the
leaking bits of code *very* quickly. then a tool like dike.rb can
identify the exact lines.
it all starts feeling like we are back to c++ doesn't it ;-)
cheers
--
a @ codefoepople.com