Help tracking down nasty SegFault bug during GC

[Please excuse the possible duplicate posting...]

This May, I offered a $2000 USD reward for anyone who
managed to fix this bug.  Well, unfortunately no one's claimed
it, so I'm up to my neck eval.c and gc.c code trying to track the
problem down myself :-(
  See:  ruby-core:11368.  Note that the reward
is no longer offered.

[ Mercenary types can stop reading here ]

Since May, I have managed to reproduce the bug on Ruby 1.8.6 p110
running on a Pentium IV laptop running Gentoo Linux (2.6.22 kernel).

I have not been able to reproduce it in any small, self-contained
test case.

The segfault always occurs in thread_mark() (in eval.c) at
the point where it is marking the thread's active frames
associated with its block list:

    while (block) {
        block = ADJ(block);
        rb_gc_mark_frame(&block->frame);
        block = block->prev;
    }

It passes a bogus frame pointer into rb_gc_mark_frame after
a couple hours of running our multi-threaded application.
Note that the only non-standard C library we use is termios.

I have now instrumented this code as follows:

    while (block) {
        if (!STACK(block) && !is_pointer_to_heap(block)) {
          rb_warn("thread_mark:  invalid block @0x%08x", block);
          break;
        }

        block = ADJ(block);
        rb_gc_mark_frame(&block->frame);
        block = block->prev;
    }


The "invalid block" warning is emitted after just a few seconds
of operation.  It is never emitted during extensive simulation runs.
This leads me to suspect that termios may be to blame.  But, I
don't see how...

My first question is:

Is it true that all blocks associated with a given thread must be
either on the heap or on its stack?

It looks like I've somehow managed to get a block from another thread
linked into this one's block list.  Does this ever occur in
normal operation of the interpreter?

Is there a convenient way to get a ruby stack backtrace from within GDB
after stopping at a breakpoint?

I'd really like see the output of "caller" at the point where this error
occurs.

I guess what I'll try next is to raise an exception at this breakpoint
and see if I can get a backtrace that way...

Has anyone seen similar crashes in the past and, if so, what turned
out to be their root cause?

- brent