From: Matt Armstrong <matt@...>
Date: 2002-02-15T01:26:14+09:00
Subject: Re: Possible bug -- ruby cvs (1.7.2 2002-02-10) interpreter seg fault

nobu.nokada@softhome.net writes:

> Hi,
>
> At Wed, 13 Feb 2002 13:56:51 -0700,
> Matt Armstrong <matt@lickey.com> wrote:
>> Should Ruby ever seg fault when it runs out of memory?  That is the
>> bug I'm most concerned about.
>
> Perhaps, you didn't see [BUG]... message at the fault, it means real
> stack overflow and nothing can be done.  Operationg sysetm kills the
> program immediately.  It can be trapped with sigaltstack() under
> POSIX system, but no way to distinguish it from other SEGV.

This makes a lot of sense, thanks.


>> I do not completely understand your answer -- what is "compilation"
>> for Ruby?  When is GC disabled in my program above?  Hmm...I see
>> that Tempfile uses SimpleDelegator which uses eval, so is that
>> causing a leak?  I did experiment with GC.start and it still
>> quickly runs out of memory.
>
> Here "compilation" means the translation from source code to
> internal structure.  load, require and also eval do it.  Accurately,
> it's not a leak, "leaked" memory will be freed at next GC.  But in
> your sample the next GC has no chance to occur.

I appreciate your efforts to explain this to me.  :-) I am still
confused here.  Are you saying that with the program below GC will not
(automatically) happen for its entire run?  I don't understand why.
If it has something to do with Ruby's compilation stage -- I don't
understand how ruby can execute the loop without finishing its
compilation stage.  Hmm...

    require 'tempfile'

    while true
      tempfile = nil
      begin
        tempfile = Tempfile.new('tempfile-test')
      ensure
        tempfile.close(true) unless tempfile.nil?
      end
    end



>> I also found a possible leak with ObjectSpace.define_finalizer.  I
>> think the finalizer proc is never freed.
> (snip)
>> I find that this program chews up memory until it runs out (and the
>> CVS version of ruby then seg faults):
>> 
>>     loop {
>>       string = "a"
>>       ObjectSpace.define_finalizer(string) {
>>       }
>>     }
>
> Since the finalizer proc shares the context which contains the
> reference to the string with the loop block, the string never be
> freed.
>
>> Since Tempfile uses a new proc for the finalizer of each new object,
>> this is bad.
>
> Tempfile uses a class method `callback' to avoid it.  It's not
> a problem.

I suppose you have to be very careful with finalizers!

-- 
matt