[ruby-core:44604] Re: [ruby-trunk - Bug #6246] 1.9.3-p125 intermittent segfault

> 
/home/deploy/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9(rb_gc_call_finalizer_at_exit+0x219) [0x7f9f37246359] gc.c:3044
> /home/deploy/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9(ruby_cleanup+0x1ec) [0x7f9f37233fac] eval.c:101
> /home/deploy/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9(ruby_run_node+0x25) [0x7f9f37234205] eval.c:244

So we're cleaning up, and:

> #0  st_lookup (table=0x0, key=792, value=0x7fffffffc858) at st.c:330
> #1  0x00007ffff7b1629f in search_method (recv=<value optimized out>,
mid=792) at vm_method.c:374
> #2  rb_method_entry_get_without_cache (recv=<value optimized out>,
mid=792) at vm_method.c:393

Someone called a method on an object that had already been GC'd.

That someone is in the logging gem:

  ObjectSpace.define_finalizer self, Logging.method(:shutdown)

Ruby makes no guarantees about the order in which finalizers are called
at exit.  This can be problematic, because the finalizer may need to
perform operations on objects that have already been GC'd.

I have avoided this before in C code by explicitly checking for a GC'd
object.  But since the logging gem is ruby (not C), I don't know what it
should do.

IMO, it should have one finalizer per appender, rather than a single
finalizer that cleans up all the appenders.  But I'm not sure that would
fix the crash.

Paul