Continuatations w/multiple Threads cause segfaults in 1.8.6 & 1.6.8

Calling all cRuby core wizards!

If you run the attached example inside valgrind, among
the usual rash of uninitialized data complaints caused
by Ruby's conservative GC, you'll
note a couple invalid reads from an already freed memory block.

What appears to be happening is that the struct BLOCK allocated
at the beginning of rb_thread_start_0() is referenced by
the continuation (assigned $c4 in nestedthreadbug.rb).
After the thread ends.  rb_thread_0() frees the struct BLOCK
it malloc'ed causing the invalid memory references
to occur on the next GC mark cycle.

The example .rb file runs for about 30 seconds.

I can prevent the errors by removing the free of the struct BLOCK
malloc'ed in rb_thread_0(), but then I have a memory leak.

Can anyone replicate this bug?

Better yet, does anyone have any suggestions on how to fix it?

I tried marking struct BLOCKs referenced by Continuations
with a special "BLOCK_KEEP" (analogous to
BLOCK_DYNAMIC) flag to allow rb_thread_0()
to free only those not so marked.  This works, but it
still leaves a small memory leak.  I've got to believe
there is a fundamentally better way...

Example valgrind complaint:

==10327== Invalid read of size 4
==10327==    at 0x8067C72: thread_mark (eval.c:10205)
==10327==    by 0x80735CC: gc_mark_children (gc.c:998)
==10327==    by 0x80731FF: gc_mark (gc.c:787)
==10327==    by 0x8073141: rb_gc_mark_maybe (gc.c:756)
==10327==    by 0x80D4FAF: val_marker (variable.c:420)
==10327==    by 0x80D5042: mark_global_entry (variable.c:465)
==10327==    by 0x80C5285: st_foreach (st.c:487)
==10327==    by 0x80D50A7: rb_gc_mark_global_tbl (variable.c:478)
==10327==    by 0x8074227: garbage_collect (gc.c:1440)
==10327==    by 0x8074289: rb_gc (gc.c:1469)
==10327==    by 0x807429B: rb_gc_start (gc.c:1486)
==10327==    by 0x805F620: call_cfunc (eval.c:5697)
==10327==  Address 0x426CB08 is 104 bytes inside a block of size 108 free'd
==10327==    at 0x40212AC: free (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10327==    by 0x8064388: blk_free (eval.c:8255)
==10327==    by 0x806AB31: rb_thread_start_0 (eval.c:12108)
==10327==    by 0x806AEC9: rb_thread_initialize (eval.c:12252)
==10327==    by 0x805F5E6: call_cfunc (eval.c:5691)
==10327==    by 0x805EB74: rb_call0 (eval.c:5850)
==10327==    by 0x8060126: rb_call (eval.c:6097)
==10327==    by 0x80604C4: rb_funcall2 (eval.c:6233)
==10327==    by 0x806301A: rb_obj_call_init (eval.c:7629)
==10327==    by 0x806ADD8: rb_thread_s_new (eval.c:12206)
==10327==    by 0x805F60A: call_cfunc (eval.c:5694)
==10327==    by 0x805EB74: rb_call0 (eval.c:5850)


-- 
 Brent Roman
 mailto:[e-mail]  http://www.mbari.org/~brent