From: Eric Mahurin <eric_mahurin@...>
Date: 2005-10-16T07:17:49+09:00
Subject: Re: Help! define_method leaking procs...

--- ES <ruby-ml@magical-cat.org> wrote:

> Eric Mahurin wrote:
> > --- Ryan Davis <ryand-ruby@zenspider.com> wrote:
> > 
> > 
> >>On Oct 15, 2005, at 11:36 AM, Jamis Buck wrote:
> >>
> >>
> >>>A plea for help, here... The rails core team is hacking
> >>
> >>like mad  
> >>
> >>>this weekend at RubyConf, and my assignment has been to
> >>
> >>track down  
> >>
> >>>and fix the memory leak in development mode. Here's what
> is
> >>
> >>known  
> >>
> >>>about this leak:
> >>>
> >>>1. It only occurs in development mode (production mode
> does
> >>
> >>not  
> >>
> >>>exhibit the leak)
> >>>2. It only occurs under FastCGI (running under WEBrick
> does
> >>
> >>not  
> >>
> >>>exhibit the leak)
> >>>3. The leak is due to an accumulation of Proc objects used
> >>
> >>with  
> >>
> >>>define_method, primarily in ActiveRecord (the
> >>
> >>define_method's in  
> >>
> >>>question are used to create the dynamic "has_one",
> >>
> >>"belongs_to",  
> >>
> >>>"has_many", and "habtm" accessors). The leak may also be
> >>
> >>due to  
> >>
> >>>define_method's used in ActionMailer, as well.
> >>
> >>Someone on IRC made this claim a while ago so I looked into
> >>it. Doing  
> >>tens of thousands of define_methods certainly increased the
> >>memory  
> >>footprint, but explicit calls to GC.start every 100 calls
> or
> >>so kept  
> >>it to a bare minimum. I don't think it is a real leak, but
> I
> >>could be  
> >>wrong. I can talk to you about it in more depth if you grab
> >>me later  
> >>today or tomorrow.
> > 
> > 
> > 
> > Take a look at this thread:
> > 
> >
>
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/3ad49507f2086e22/ac92a1373161035e?q=mahurin&rnum=4#ac92a1373161035e
> > 
> > I demonstrated some example code with a memory leak with
> > lambdas.
> 
> I still do not think this is a memory leak. It is, perhaps,
> memory
> that the implementer may not realize will be consumed but its
> whereabouts are known and it is accessible.
> 
> E

So you definition of "memory leak" says that it is not a memory
leak if the unused memory can still be freed by the program. 
With the example I gave, you could still free the memory using
the Proc#binding with eval to assign the unused variables to
nil.  But, here is a slightly modified example where (using
#define_method) where you lose this access:

n=2**13;(1..n).each{|i|
a=(1..i).to_a;self.class.send(:define_method,:"f#{i}"){i*i}};GC.start;
IO.readlines("/proc/#{Process.pid}/status").grep(/VmSize/).display'
VmSize:   172028 kB

As far as I know, you can't access any of thoses a's after you
get out of the each loop.  I call that a memory leak by any
definition.

Here is the fixed version:

ruby -e '
n=2**13;(1..n).each{|i|
a=(1..i).to_a;self.class.send(:define_method,:"f#{i}"){i*i};a=nil};GC.start;
IO.readlines("/proc/#{Process.pid}/status").grep(/VmSize/).display'
VmSize:    11504 kB



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/