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