Eric Mahurin wrote:
> --- 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. 

Yes. As far as I knew, this was the only sensible definition.
If there is a problem, it is not a memory leak (as most or all
C programmers understand the term anyway); changing the term might
yield a more successful debate.

> 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

E