# Finalizer not getting called

**URL:** <https://www.ruby-forum.com/t/finalizer-not-getting-called/111050>\
**Category:** Ruby\
**Created:** [August 2, 2007, 6:09am UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050 "2007-08-02T06:09:19Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 6:09am UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/1 "2007-08-02T06:09:19Z")

</div>

The finalizer is not getting called in this code – it just prints  
‘exiting’. What’s wrong? I’m running it on v1.8.6 on Windows Vista.

class A  
def initialize  
ObjectSpace.define\_finalizer(self, proc{|id| puts “finalizing  
#{id}”})  
end  
end  
a = A.new  
a = nil  
GC.start  
sleep(5)  
puts ‘exiting’

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 7:53am UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/2 "2007-08-02T07:53:27Z")

</div>

Joshua C. wrote:

> The finalizer is not getting called in this code – it just prints  
> ‘exiting’. What’s wrong? I’m running it on v1.8.6 on Windows Vista.
> 
> class A  
> def initialize  
> ObjectSpace.define\_finalizer(self, proc{|id| puts “finalizing  
> #{id}”})  
> end  
> end  
> a = A.new  
> a = nil  
> GC.start  
> sleep(5)  
> puts ‘exiting’

I used this example with Windows2000 and the same result. It works when  
I put the finalizer definition outside of the class definition.

> > > > > Code \>\>\>\>\>  
> > > > > class A  
> > > > > def initialize  
> > > > > puts “initializing #{self.object\_id}”

# ObjectSpace.define\_finalizer(self, proc{|id| puts "finalizing

#{id}"})  
end  
end  
a = A.new  
puts “created #{a.object\_id}”  
ObjectSpace.define\_finalizer(a, proc{|id| puts “finalizing #{id}”})  
a = nil  
GC.start  
puts ‘exiting’

> > > > > Output \>\>\>\>\>  
> > > > > initializing 24036900  
> > > > > created 24036900  
> > > > > exiting  
> > > > > finalizing 24036900
> 
> > > > > EOE \>\>\>\>\>

When I change your original code a little bit, there will be an  
interesting result…

> > > > > Code \>\>\>\>\>  
> > > > > class A  
> > > > > def initialize  
> > > > > puts “initializing #{self.object\_id}”  
> > > > > ObjectSpace.define\_finalizer(self, proc{|id| puts “finalizing  
> > > > > #{id}”})  
> > > > > end  
> > > > > end  
> > > > > a = A.new  
> > > > > puts “created #{a.object\_id}”  
> > > > > #ObjectSpace.define\_finalizer(a, proc{|id| puts “finalizing #{id}”})  
> > > > > a = nil  
> > > > > GC.start  
> > > > > ObjectSpace.each\_object(A){|o|puts “still there: #{o.object\_id}”}  
> > > > > puts ‘exiting’
> 
> > > > > Output \>\>\>\>\>  
> > > > > initializing 24036690  
> > > > > created 24036690  
> > > > > still there: 24036690  
> > > > > exiting
> 
> > > > > EOE \>\>\>\>\>

…which means, that the object was not destroyed by the GC. I don’t see  
any additional actual reference to the object and don’t understand this.

Wolfgang Nádasi-Donner

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 10:22am UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/3 "2007-08-02T10:22:20Z")

</div>

On Aug 1, 10:53 pm, “Wolfgang Nádasi-donner” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > a = A.new  
> > a = nil  
> > GC.start  
> > sleep(5)  
> > puts ‘exiting’
> 
> …which means, that the object was not destroyed by the GC. I don’t see  
> any additional actual reference to the object and don’t understand this.

There is actually a simple reason. Remember that you’re passing a  
block, ie. a closure, to define\_finalizer. That closure holds on to  
the stuff like self, which in this case is the object to be finalized.  
Thus the finalizer code is actually keeping the object alive.

Use define\_finalizer outside the object associates the block with a  
context that does not contain the object to be finalized (once the  
local is set to nil), so it’s actually garbage, and the finalizer  
runs.

This is the most common misstep when using finalizers, and they should  
be avoided if at all possible, because remember, there is no guarantee  
when a finalizer will run, or if it will even run at all.

- Evan P. // evan () fallingsnow [] net

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 7:30pm UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/4 "2007-08-02T19:30:54Z")

</div>

removed\_email\_address@domain.invalid wrote:

> …  
> There is actually a simple reason. Remember that you’re passing a  
> block, ie. a closure, to define\_finalizer. That closure holds on to  
> the stuff like self, which in this case is the object to be finalized.  
> Thus the finalizer code is actually keeping the object alive.
> 
> Use define\_finalizer outside the object associates the block with a  
> context that does not contain the object to be finalized (once the  
> local is set to nil), so it’s actually garbage, and the finalizer  
> runs.

I’m not familiar with all the nuances for blocks, but I only see that  
the block makes no reference to self. Why does it need to hold on to a  
reference to self?

With traditional C code, when you use a library, the client app often  
needs to manually call init and teardown. With C++ and Java, you can  
let the library do the init and teardown with constructors and  
destructors, so you don’t need to depend on the app to call init and  
teardown at the right time. This is good from a software engineering  
perspective since it reduces the number of things entangling the client  
and library.

I’m primarily concerned about the teardown happening at all and  
secondarily about it happening as soon as possible. How do I guarantee  
the eventual execution of some teardown code without depending on the  
client (in this case, whoever initialized the instance)? Do I just move  
the call to define\_finalizer into another method and call that method  
from initialize?

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 12:06pm UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/5 "2007-08-02T12:06:43Z")

</div>

removed\_email\_address@domain.invalid wrote:

> There is actually a simple reason. Remember that you’re passing a  
> block, ie. a closure, to define\_finalizer. That closure holds on to  
> the stuff like self, which in this case is the object to be finalized.  
> Thus the finalizer code is actually keeping the object alive.

Oh yes, this has to be overlook easily. Usually I don’t care about the  
time objects will be destroyed.

removed\_email\_address@domain.invalid wrote:

> …there is no guarantee … if it will even run at all.

I understand from the description, that a finalizer will run for an  
object directly after GC destroyes it. It will not be called if the  
program ends without calling GC ever, but if GC destroyes it, the call  
will be guaranteed. Is this correct?

Wolfgang Nádasi-Donner

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 7:47pm UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/6 "2007-08-02T19:47:57Z")

</div>

Joshua C. wrote:

> > runs.  
> > perspective since it reduces the number of things entangling the client  
> > and library.
> 
> I’m primarily concerned about the teardown happening at all and  
> secondarily about it happening as soon as possible. How do I guarantee  
> the eventual execution of some teardown code without depending on the  
> client (in this case, whoever initialized the instance)? Do I just move  
> the call to define\_finalizer into another method and call that method  
> from initialize?  
> The Ruby way is not to rely on a finalizer, but to define your setup and  
> teardown code around a yield thus:

class Foo  
def do\_work  
setup\_bits  
yield  
teardown\_bits  
end  
end

Then you use it like this:

Foo.new.do\_work do  
whatever\_you\_want  
end

That way the execution sequence is

- setup\_bits
- whatever\_you\_want
- teardown\_bits

This is far simpler than relying on finalizer behaviour, which I find  
rather impenetrable.

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 2, 2007, 7:50pm UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/7 "2007-08-02T19:50:38Z")

</div>

Joshua C. wrote:

> I’m not familiar with all the nuances for blocks, but I only see that  
> the block makes no reference to self. Why does it need to hold on to a  
> reference to self?

Blocks act as closures, which means, that variables not defined as block  
parameter but used inside the block, will be taken from the environment  
in which the block was defined. In this case the value of “self” - which  
refers the new defined object - must be saved for this purpose.

If you define the block outside of initialize, it will work.

> > > > > Code \>\>\>\>\>  
> > > > > class A  
> > > > > def initialize(b)  
> > > > > puts “initializing #{self.object\_id}”  
> > > > > ObjectSpace.define\_finalizer(self, b)  
> > > > > end  
> > > > > end  
> > > > > a = A.new(proc{|id| puts “finalizing #{id}”})  
> > > > > puts “created #{a.object\_id}”  
> > > > > a = nil  
> > > > > GC.start  
> > > > > ObjectSpace.each\_object(A){|o|puts “still there: #{o.object\_id}”}  
> > > > > puts ‘exiting’
> 
> > > > > Result \>\>\>\>\>  
> > > > > initializing 24036640  
> > > > > created 24036640  
> > > > > finalizing 24036640  
> > > > > exiting
> 
> > > > > EOE \>\>\>\>\>

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 3, 2007, 2:42am UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/8 "2007-08-03T02:42:39Z")

</div>

Florian F. wrote:

> Another possibility is to use a binding, that doesn’t

Ahmmm. Let’s continue here: …contain the value, perhaps  
TOPLEVEL\_BINDING and evaluate a string in this context:

class A  
def initialize  
ObjectSpace.define\_finalizer(self,  
eval(‘proc{|id| puts “finalizing #{id}”}’, TOPLEVEL\_BINDING))  
end  
end

def foo  
a = A.new  
end  
foo # don’t taint the toplevel  
GC.start  
sleep(5)  
puts ‘exiting’

Like I said, it’s not pretty to use finalizers in Ruby and you perhaps  
shouldn’t. Using the yield pattern mentioned by Alex Y. is perhaps a  
better solution to your problem.

---

<div class="post-metadata">

**Author:** ![syncopated](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/85f322/32.png) [@syncopated](https://www.ruby-forum.com/u/syncopated)\
**Post date:** [August 3, 2007, 2:28am UTC](https://www.ruby-forum.com/t/finalizer-not-getting-called/111050/9 "2007-08-03T02:28:38Z")

</div>

Joshua C. wrote:

> a = nil  
> GC.start  
> sleep(5)  
> puts ‘exiting’

If the answer is finalizer in Ruby, then it’s very likely, that you’re  
working on the wrong problem. They are quite difficult to get right  
(=not referencing the value to be finalized anywhere). You could use a  
class variable for example:

class A  
@@foo = proc{|id| puts “finalizing #{id}”}

def initialize  
ObjectSpace.define\_finalizer(self, @@foo)  
end  
end

Another possibility is to use a binding, that doesn’t