From: Rick DeNatale <rick.denatale@...>
Date: 2008-01-10T03:26:49+09:00
Subject: Re: why does this code leak?

On Jan 9, 2008 11:45 AM, ara howard <ara.t.howard@gmail.com> wrote:
>
> On Jan 9, 2008, at 9:39 AM, dan yoder wrote:
>
> > I realize the scope of the lambda invocation is different in this
> > example, but since the behavior is so similar, I thought it likely
> > pointed to the same underlying issue.
>
> i think it's actually some strange interaction with yaml.  check this
> out:
...
> if ARGV.detect{|arg| arg["leak"]}
>   require "yaml"
>   7.times {
>     GC.start
>     y c.name => ObjectSpace.each_object(c){}
>     c.new
>   }
> else
>   7.times {
>     GC.start
>     puts "---"
>     puts "#{ c.name }: #{ ObjectSpace.each_object(c){} }"
>     c.new
>   }
> end
>
> cfp2:~ > ruby a.rb
> ---
> Array: 6

>
> cfp2:~ > ruby a.rb leak
> ---
> Array: 21

Not sure how you got there Ara, I don't see where the OP ever mentioned YAML.

I think the key is where the lambda is created. The lambda is
capturing the binding.

In the first case the lambda is being created in the bindig context of
the class, and in particular self is the class.

In the second case, the lambda is being created in the binding context
of the new instance, and self is that new instance, so the lambda in
the finalizer is hanging on to it.

That's my theory anyway.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/