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?
In message “Re: Confusing array garbage collection, how to get valid
heap snapshot?”
on Wed, 23 May 2007 09:40:04 +0900, Greg F. [email protected]
writes:
|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.
It sometimes happens. I am afraid the array address is pointed from
somewhere in the machine stack.
It sometimes happens. I am afraid the array address is pointed from
somewhere in the machine stack.
matz.
Ah. Could I get some pointers in the source to look to better
understand this dynamic? (How and why this stack is retained
within ruby after the return of the ruby method?)
In message “Re: Confusing array garbage collection, how to get valid
heap snapshot?”
on Wed, 23 May 2007 11:55:05 +0900, Greg F. [email protected]
writes:
|Ah. Could I get some pointers in the source to look to better
|understand this dynamic? (How and why this stack is retained
|within ruby after the return of the ruby method?)
gc.c especially in the function garbage_collect().
matz.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.