We are working on tracking down a memory leak, and are hoping to use
heap snapshotting to find the culprit. Using the neat bleak_house
library:
I have got snapshotting working on my local machine. Note this library
does not go through ObjectSpaces, but uses a custom ruby build, so its
much more accurate in showing the true state of the heap. However,
there seems to be a bit of a problem, this simple script I wrote for
testing purposes:
Snapshot here
a = Array.new(1000) { Object.new }
a = nil
1.upto(20) { GC.start; ObjectSpace.garbage_collect; sleep 1; }
Snapshot here
Shows that the 1000 objects in the array are still on the heap in the
second snapshot. Now, I realize GC.start makes no guarantees about
actually removing the objects marked, but it seems that in this case
they should go away since I am calling it so aggressively over such a
long period. What is really strange however is that if I all a.clear
before setting a to nil, the objects do go away upon the first
GC.start. So, either there is something still holding those references
in the above case, or the GC is extraordinarily conservative in
relation to GC.start.
I’ve also tried wrapping this code up into a class, putting the array
into an instance variable, and I get the same behavior. (This was to
make sure there are no procs or something at the root scope holding
these guys.)
In order to effectively track down memory leaks, there needs to be the
concept of a totally GC’ed heap snapshot. It appears based upon the
above behavior this is difficult to get. If the above code was under
test my heap snapshot would show a ‘leak’ of 1000 objects even though
my code was correctly dereferencing them. Is there something I am
missing here?