# GC oddness **URL:** \ **Category:** ruby-talk\ **Created:** [6 July 2006 14:58 UTC](https://rubytalk.org/t/gc-oddness/28693 "2006-07-06T14:58:27Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [6 July 2006 14:58 UTC](https://rubytalk.org/t/gc-oddness/28693/1 "2006-07-06T14:58:27Z")
Hi all, Can someone smarter tell me why this fails? I'm expecting the TestDir to get GC'd when I call GC.start in the test, but something's obviously keeping a reference lying around. I just can't see what it is... > **···** > > ---------------------- > require 'test/unit' > require 'fileutils' > > class TestDir >    def TestDir.set\_finalizer(testdir, dir) >      ObjectSpace.define\_finalizer(testdir, proc{|id| >        FileUtils.rm\_rf(dir) >      } >    end >    def initialize(dir) >      FileUtils.mkdir(dir) >      TestDir.set\_finalizer(self, dir) >    end > end > > class DestroyTest \< Test::Unit::TestCase >    def test\_destroy >      a = TestDir.new('test\_dir') >      a = nil >      GC.start >      assert !File.directory?('test\_dir') >    end > end > ---------------------------- > > It's got me a bit stumped. > > Thanks, > -- > Alex ---
**Author:** ![Nobuyoshi\_Nakada1](https://avatars.discourse-cdn.com/v4/letter/n/9f8e36/32.png) [@Nobuyoshi\_Nakada1](https://rubytalk.org/u/Nobuyoshi_Nakada1)\ **Post date:** [6 July 2006 15:10 UTC](https://rubytalk.org/t/gc-oddness/28693/2 "2006-07-06T15:10:11Z")
Hi, At Thu, 6 Jul 2006 23:58:27 +0900, Alex Young wrote in [ruby-talk:200382]: > Can someone smarter tell me why this fails? I'm expecting the TestDir > to get GC'd when I call GC.start in the test, but something's obviously > keeping a reference lying around. I just can't see what it is... The finalizer proc refers testdir. > ---------------------- > require 'test/unit' > require 'fileutils' > > class TestDir >    def TestDir.finalizer(dir)        proc{|id| >        FileUtils.rm\_rf(dir) >      } >    end >    def initialize(dir) >      FileUtils.mkdir(dir)        ObjectSpace.define\_finalizer(self, TestDir.finalizer(dir)) > **···** > > >    end > > end > > -- > Nobu Nakada ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [6 July 2006 15:46 UTC](https://rubytalk.org/t/gc-oddness/28693/3 "2006-07-06T15:46:50Z")
nobu@ruby-lang.org wrote: > Hi, > > At Thu, 6 Jul 2006 23:58:27 +0900, > Alex Young wrote in [ruby-talk:200382]: > > > Can someone smarter tell me why this fails? I'm expecting the TestDir to get GC'd when I call GC.start in the test, but something's obviously keeping a reference lying around. I just can't see what it is... > > The finalizer proc refers testdir. I thought it might be that, but this also fails: > **···** > > ----------------------------- > require 'test/unit' > require 'fileutils' > > class TestDir >    @@dir = nil >    @@clearup = proc {|id| FileUtils.rm\_rf(@@dir)} > >    def TestDir.set\_finalizer(testdir, dir) >      @@dir = dir >      ObjectSpace.define\_finalizer(testdir, @@clearup) >    end >    def initialize(dir) >      FileUtils.mkdir(dir) >      TestDir.set\_finalizer(self, dir) >    end > end > > class DestroyTest \< Test::Unit::TestCase >    def test\_destroy >      a = TestDir.new('test\_dir') >      a = nil >      GC.start >      assert !File.directory?('test\_dir') >    end > end > ---------------------------- > > testdir hasn't come into existence when the proc's created this time, so I don't see how it can be keeping a reference to it, or how a finalizer proc keeping a reference to the object that's being finalized can stop GC - if that's the case, how does the object ever get GC'd? What have I missed? > > -- > Alex ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [6 July 2006 23:41 UTC](https://rubytalk.org/t/gc-oddness/28693/4 "2006-07-06T23:41:43Z")
> > Hi, > > At Thu, 6 Jul 2006 23:58:27 +0900, > > Alex Young wrote in [ruby-talk:200382]: > > > > > Can someone smarter tell me why this fails? I'm expecting the TestDir to get GC'd when I call GC.start in the test, but something's obviously keeping a reference lying around. I just can't see what it is... > > > > The finalizer proc refers testdir. > > I thought it might be that, but this also fails: > > ----------------------------- > require 'test/unit' > require 'fileutils' > > class TestDir >   @@dir = nil >   @@clearup = proc {|id| FileUtils.rm\_rf(@@dir)} > >   def TestDir.set\_finalizer(testdir, dir) >     @@dir = dir >     ObjectSpace.define\_finalizer(testdir, @@clearup) >   end >   def initialize(dir) >     FileUtils.mkdir(dir) >     TestDir.set\_finalizer(self, dir) >   end > end > > class DestroyTest \< Test::Unit::TestCase >   def test\_destroy >     a = TestDir.new('test\_dir') >     a = nil >     GC.start >     assert !File.directory?('test\_dir') >   end > end > ---------------------------- > > testdir hasn't come into existence when the proc's created this time, so I don't see how it can be keeping a reference to it Ruby's garbage collector is conservative, so their may be references to TestDir lying around on the C stack. > or how a finalizer proc keeping a reference to the object that's being finalized can stop GC - if that's the case, how does the object ever get GC'd? What have I missed? Procs contain the environment of their creation. In other words, they keep references to all variables visible at their creation time including self. When using a finalizer proc you must ensure that finalizer doesn't refer to the object it is supposed to clean up after. weakref.rb contains an example of use of finalizers, including a map between object ids and objects to be cleaned up after. PS: What you want to do is easier with blocks: def testdir(dir)    FileUtils.mkdir dir    begin      yield    ensure      FileUtils.rm\_rf dir    end end testdir 'mytempdir' do    # ... end > **···** > > On Jul 6, 2006, at 8:46 AM, Alex Young wrote: > > > nobu@ruby-lang.org wrote: > > -- > Eric Hodel - drbrain@segment7.net - [http://blog.segment7.net](http://blog.segment7.net) > This implementation is HODEL-HASH-9600 compliant > > [http://trackmap.robotcoop.com](http://trackmap.robotcoop.com) ---
**Author:** ![Yohanes\_Santoso1](https://avatars.discourse-cdn.com/v4/letter/y/ccd318/32.png) [@Yohanes\_Santoso1](https://rubytalk.org/u/Yohanes_Santoso1)\ **Post date:** [7 July 2006 00:14 UTC](https://rubytalk.org/t/gc-oddness/28693/5 "2006-07-07T00:14:42Z")
Alex Young \ writes: > > Hi, > > At Thu, 6 Jul 2006 23:58:27 +0900, > > Alex Young wrote in [ruby-talk:200382]: > > > > > Can someone smarter tell me why this fails? I'm expecting the > > > TestDir to get GC'd when I call GC.start in the test, but > > > something's obviously keeping a reference lying around. I just > > > can't see what it is... > > > > The finalizer proc refers testdir. > > I thought it might be that, but this also fails: It does not fail on me: require 'test/unit' require 'fileutils' class TestDir    @@dir = nil    @@clearup = proc {|id| FileUtils.rm\_rf(@@dir); puts "Cleaned"}    def TestDir.set\_finalizer(testdir, dir)      @@dir = dir      ObjectSpace.define\_finalizer(testdir, @@clearup)    end    def initialize(dir)      FileUtils.mkdir(dir)      TestDir.set\_finalizer(self, dir)    end end class DestroyTest \< Test::Unit::TestCase    def test\_destroy      a = TestDir.new('test\_dir')      a = nil      GC.start      puts "GC invoked"      assert !File.directory?('test\_dir')      puts "Done"    end end $ ruby ./gc.rb Loaded suite ./gc Started Cleaned GC invoked Done . Finished in 0.015623 seconds. 1 tests, 1 assertions, 0 failures, 0 errors $ ruby -v ruby 1.8.4 (2005-12-24) [i386-linux] Which OS and ruby are you using? YS. > **···** > > > nobu@ruby-lang.org wrote: ---
**Author:** ![Juergen\_Strobel](https://avatars.discourse-cdn.com/v4/letter/j/439d5e/32.png) [@Juergen\_Strobel](https://rubytalk.org/u/Juergen_Strobel)\ **Post date:** [8 July 2006 05:30 UTC](https://rubytalk.org/t/gc-oddness/28693/6 "2006-07-08T05:30:38Z")
To get slightly off the track, I don't think using finalizers is the best way to tackle your problem. Are you per chance coming from C++? The RAI-pattern (Resource Aquisition is Initialisation) is very C++-specific and doesn't work well for any language where destructors (or finalizers) don't get to run at fixed times. Consider instead something more rubyish like this: def with\_testdir(dir)   raise "needs a block" unless block\_given?   setup(dir)   yield dir # calls your given block ensure   cleanup(dir) # is executed right after your block finishes end with\_test\_dir("/tmp/test") do |dir| puts "now working in #{dir}" # your code end -Jürgen > **···** > > On Fri, Jul 07, 2006 at 12:46:50AM +0900, Alex Young wrote: > > > nobu@ruby-lang.org wrote: > > \>Hi, > > \> > > \>At Thu, 6 Jul 2006 23:58:27 +0900, > > \>Alex Young wrote in [ruby-talk:200382]: > > \> > > \>\>Can someone smarter tell me why this fails? I'm expecting the TestDir > > \>\>to get GC'd when I call GC.start in the test, but something's obviously > > \>\>keeping a reference lying around. I just can't see what it is... > > \> > > \> > > \>The finalizer proc refers testdir. > > I thought it might be that, but this also fails: > > > > ----------------------------- > > require 'test/unit' > > require 'fileutils' > > > > class TestDir > >   @@dir = nil > >   @@clearup = proc {|id| FileUtils.rm\_rf(@@dir)} > > > >   def TestDir.set\_finalizer(testdir, dir) > >     @@dir = dir > >     ObjectSpace.define\_finalizer(testdir, @@clearup) > >   end > >   def initialize(dir) > >     FileUtils.mkdir(dir) > >     TestDir.set\_finalizer(self, dir) > >   end > > end > > > > class DestroyTest \< Test::Unit::TestCase > >   def test\_destroy > >     a = TestDir.new('test\_dir') > >     a = nil > >     GC.start > >     assert !File.directory?('test\_dir') > >   end > > end > > ---------------------------- > > > > testdir hasn't come into existence when the proc's created this time, so > > I don't see how it can be keeping a reference to it, or how a finalizer > > proc keeping a reference to the object that's being finalized can stop > > GC - if that's the case, how does the object ever get GC'd? What have I > > missed? > > > > -- > > Alex > > -- > The box said it requires Windows 95 or better so I installed Linux ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [7 July 2006 07:57 UTC](https://rubytalk.org/t/gc-oddness/28693/7 "2006-07-07T07:57:27Z")
Yohanes Santoso wrote: \ > It does not fail on me: > > require 'test/unit' > require 'fileutils' > > class TestDir >    @@dir = nil >    @@clearup = proc {|id| FileUtils.rm\_rf(@@dir); puts "Cleaned"} > >    def TestDir.set\_finalizer(testdir, dir) >      @@dir = dir >      ObjectSpace.define\_finalizer(testdir, @@clearup) >    end >    def initialize(dir) >      FileUtils.mkdir(dir) >      TestDir.set\_finalizer(self, dir) >    end > end > > class DestroyTest \< Test::Unit::TestCase >    def test\_destroy >      a = TestDir.new('test\_dir') >      a = nil >      GC.start >      puts "GC invoked" >      assert !File.directory?('test\_dir') >      puts "Done" >    end > end > > $ ruby ./gc.rb > Loaded suite ./gc > Started > Cleaned > GC invoked > Done > . > Finished in 0.015623 seconds. > > 1 tests, 1 assertions, 0 failures, 0 errors That's... odd. > $ ruby -v > ruby 1.8.4 (2005-12-24) [i386-linux] > > Which OS and ruby are you using? $ ruby -v ruby 1.8.4 (2005-12-24) [i486-linux] It's on Ubuntu 5.10. > **···** > > -- > Alex ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [7 July 2006 08:08 UTC](https://rubytalk.org/t/gc-oddness/28693/8 "2006-07-07T08:08:15Z")
Eric Hodel wrote: > \ > ----------------------------- > > > require 'test/unit' > > require 'fileutils' > > > > class TestDir > >   @@dir = nil > >   @@clearup = proc {|id| FileUtils.rm\_rf(@@dir)} > > > >   def TestDir.set\_finalizer(testdir, dir) > >     @@dir = dir > >     ObjectSpace.define\_finalizer(testdir, @@clearup) > >   end > >   def initialize(dir) > >     FileUtils.mkdir(dir) > >     TestDir.set\_finalizer(self, dir) > >   end > > end > > > > class DestroyTest \< Test::Unit::TestCase > >   def test\_destroy > >     a = TestDir.new('test\_dir') > >     a = nil > >     GC.start > >     assert !File.directory?('test\_dir') > >   end > > end > > ---------------------------- \ > > or how a finalizer proc keeping a reference to the object that's being finalized can stop GC - if that's the case, how does the object ever get GC'd? What have I missed? > > Procs contain the environment of their creation. In other words, they keep references to all variables visible at their creation time including self. When using a finalizer proc you must ensure that finalizer doesn't refer to the object it is supposed to clean up after. That's what the code above ensures, I \*think\*... > weakref.rb contains an example of use of finalizers, including a map between object ids and objects to be cleaned up after. Thanks, I'll take a look at that. > PS: What you want to do is easier with blocks: > > def testdir(dir) >   FileUtils.mkdir dir >   begin >     yield >   ensure >     FileUtils.rm\_rf dir >   end > end > > testdir 'mytempdir' do >   # ... > end Unfortunately, that's not going to work here. What I'm trying to do is create a drop-in replacement for a small subset of Array's functionality which serialises its contents to disk rather than keeping it in memory, for some existing code. The idea is that a new instance creates a directory for itself on creation, and cleans up after itself when it gets GC'd. The existing code structure doesn't lend itself well to blocking. Of course, since everything gets GC'd on exit anyway, it's not exactly a huge problem, but it is making testing a tad tricky, and surprised me somewhat... > **···** > > > On Jul 6, 2006, at 8:46 AM, Alex Young wrote: > > -- > Alex ---
**Author:** ![\_Pena\_Botp1](https://avatars.discourse-cdn.com/v4/letter/_/94ad74/32.png) [@\_Pena\_Botp1](https://rubytalk.org/u/_Pena_Botp1)\ **Post date:** [7 July 2006 08:12 UTC](https://rubytalk.org/t/gc-oddness/28693/9 "2006-07-07T08:12:47Z")
fr Alex: # That's... odd. > **···** > > # > # \> $ ruby -v > # \> ruby 1.8.4 (2005-12-24) [i386-linux] > # \> > # \> Which OS and ruby are you using? > # > # $ ruby -v > # ruby 1.8.4 (2005-12-24) [i486-linux] > # > # It's on Ubuntu 5.10. > > can't help, but fwiw, > > :~# ruby -w gc.rb > Loaded suite gc > Started > GC invoked > F > Finished in 0.102665 seconds. > >   1) Failure: > test\_destroy(DestroyTest) [gc.rb:24]: > \ is not true. > > 1 tests, 1 assertions, 1 failures, 0 errors > Cleaned > :~# uname -an > Linux pc4all 2.6.15-25-686 #1 SMP PREEMPT Wed Jun 14 11:34:19 UTC 2006 i686 GNU/Linux > :~# cat /etc/issue > Ubuntu 6.06 LTS \n \l > > kind regards -botp :~# ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [7 July 2006 20:40 UTC](https://rubytalk.org/t/gc-oddness/28693/10 "2006-07-07T20:40:38Z")
Have you looked at PStore? > **···** > > On Jul 7, 2006, at 1:08 AM, Alex Young wrote: > > > Unfortunately, that's not going to work here. What I'm trying to do is create a drop-in replacement for a small subset of Array's functionality which serialises its contents to disk rather than keeping it in memory, for some existing code. > > -- > Eric Hodel - drbrain@segment7.net - [http://blog.segment7.net](http://blog.segment7.net) > This implementation is HODEL-HASH-9600 compliant > > [http://trackmap.robotcoop.com](http://trackmap.robotcoop.com) ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [7 July 2006 10:58 UTC](https://rubytalk.org/t/gc-oddness/28693/11 "2006-07-07T10:58:23Z")
Peña wrote: > fr Alex: > # That's... odd. > # # \> $ ruby -v > # \> ruby 1.8.4 (2005-12-24) [i386-linux] > # \> # \> Which OS and ruby are you using? > # # $ ruby -v > # ruby 1.8.4 (2005-12-24) [i486-linux] > # # It's on Ubuntu 5.10. > > can't help, but fwiw, \ >   1) Failure: > test\_destroy(DestroyTest) [gc.rb:24]: > \ is not true. > > 1 tests, 1 assertions, 1 failures, 0 errors \ Thanks for that, it's good to know it's not just me... Ok, next question: which is the correct behaviour? > **···** > > -- > Alex ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [8 July 2006 12:25 UTC](https://rubytalk.org/t/gc-oddness/28693/12 "2006-07-08T12:25:20Z")
Eric Hodel wrote: > **···** > > > On Jul 7, 2006, at 1:08 AM, Alex Young wrote: > > > > > Unfortunately, that's not going to work here. What I'm trying to do is create a drop-in replacement for a small subset of Array's functionality which serialises its contents to disk rather than keeping it in memory, for some existing code. > > > > Have you looked at PStore? > > Yes. The serialisation isn't the problem - it's the tidying up afterwards. While I'm actually using YAML for the serialisation dump of the array entries, I could quite easily swap it out for PStore if it turns out that transactions become vital. I might do that anyway - PStore's mature, and my code isn't 🙂 > > -- > Alex ---
**Author:** ![Yohanes\_Santoso1](https://avatars.discourse-cdn.com/v4/letter/y/ccd318/32.png) [@Yohanes\_Santoso1](https://rubytalk.org/u/Yohanes_Santoso1)\ **Post date:** [7 July 2006 14:23 UTC](https://rubytalk.org/t/gc-oddness/28693/13 "2006-07-07T14:23:10Z")
Alex Young \ writes: > Peña wrote: > > > fr Alex: > > # That's... odd. > > # # \> $ ruby -v > > # \> ruby 1.8.4 (2005-12-24) [i386-linux] > > # \> # \> Which OS and ruby are you using? > > # # $ ruby -v > > # ruby 1.8.4 (2005-12-24) [i486-linux] > > # # It's on Ubuntu 5.10. > > can't help, but fwiw, > > \ > > >   1) Failure: > > test\_destroy(DestroyTest) [gc.rb:24]: > > \ is not true. > > 1 tests, 1 assertions, 1 failures, 0 errors > > \ > > Thanks for that, it's good to know it's not just me... Ok, next > question: which is the correct behaviour? Mine has the correct behaviour. The finaliser has no reference to the the TestDir instance being finalised. YS. ---
**Author:** ![Joel\_VanderWerf1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Joel\_VanderWerf1](https://rubytalk.org/u/Joel_VanderWerf1)\ **Post date:** [9 July 2006 00:24 UTC](https://rubytalk.org/t/gc-oddness/28693/14 "2006-07-09T00:24:26Z")
Alex Young wrote: > Eric Hodel wrote: > > > > Unfortunately, that's not going to work here. What I'm trying to do is create a drop-in replacement for a small subset of Array's functionality which serialises its contents to disk rather than keeping it in memory, for some existing code. > > > > Have you looked at PStore? > > Yes. The serialisation isn't the problem - it's the tidying up afterwards. While I'm actually using YAML for the serialisation dump of the array entries, I could quite easily swap it out for PStore if it turns out that transactions become vital. I might do that anyway - PStore's mature, and my code isn't 🙂 You might find fsdb an interesting alternative to pstore: [http://raa.ruby-lang.org/project/fsdb/](http://raa.ruby-lang.org/project/fsdb/) > **···** > > > > On Jul 7, 2006, at 1:08 AM, Alex Young wrote: > > -- >        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [7 July 2006 14:33 UTC](https://rubytalk.org/t/gc-oddness/28693/15 "2006-07-07T14:33:38Z")
Yohanes Santoso wrote: > Alex Young \ writes: \ > Thanks for that, it's good to know it's not just me... Ok, next > > > question: which is the correct behaviour? > > Mine has the correct behaviour. > > The finaliser has no reference to the the TestDir instance being > finalised. That's what I thought. Which OS are you using? Did you build your Ruby yourself? > **···** > > -- > Alex ---
**Author:** ![Alex\_Young](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Alex\_Young](https://rubytalk.org/u/Alex_Young)\ **Post date:** [10 July 2006 11:41 UTC](https://rubytalk.org/t/gc-oddness/28693/16 "2006-07-10T11:41:02Z")
Joel VanderWerf wrote: > Alex Young wrote: > > > Eric Hodel wrote: > > > > > > Unfortunately, that's not going to work here. What I'm trying to do is create a drop-in replacement for a small subset of Array's functionality which serialises its contents to disk rather than keeping it in memory, for some existing code. > > > > > > Have you looked at PStore? > > > > Yes. The serialisation isn't the problem - it's the tidying up afterwards. While I'm actually using YAML for the serialisation dump of the array entries, I could quite easily swap it out for PStore if it turns out that transactions become vital. I might do that anyway - PStore's mature, and my code isn't 🙂 > > You might find fsdb an interesting alternative to pstore: > > [http://raa.ruby-lang.org/project/fsdb/](http://raa.ruby-lang.org/project/fsdb/) That looks quite intriguing. I'll have to take a look at that. > **···** > > > > > On Jul 7, 2006, at 1:08 AM, Alex Young wrote: > > -- > Alex ---
**Author:** ![Yohanes\_Santoso1](https://avatars.discourse-cdn.com/v4/letter/y/ccd318/32.png) [@Yohanes\_Santoso1](https://rubytalk.org/u/Yohanes_Santoso1)\ **Post date:** [7 July 2006 15:11 UTC](https://rubytalk.org/t/gc-oddness/28693/17 "2006-07-07T15:11:23Z")
Alex Young \ writes: > That's what I thought. Which OS are you using? Did you build your > Ruby yourself? $ ruby -v ruby 1.8.4 (2005-12-24) [i386-linux] Debian 3.1. The ruby was locally build from debian testing's ruby-1.8.4 source package. YS.