I have recently encountered similiar problem as described on that thread, i.e., rb_bug
triggered by the GC, as a result of RBasic->flags and RBasic->klass switching variables.

I've been working to produce a simple and trivial code that can trigger the bug easily. the
result is a small code snippet, the does the following:

Launches 120 threads with a block, that does some 20,000 regexp matching. before
the thread quits, it creates an additional thread with the same block

thread_block= Proc.new do
   1.upto(20000) do
      "Hello"=~/bla/
   end
   Thread.new &thread_block
end

1.upto(120) do
   Thread.new &thread_block
end
Thread.stop

Under ruby-1.8.0(from debian's sid) the bug will be always be triggered after a few
seconds of runtime.

I have set gdb to break at the following location at gc.c - obj_free():
1150            rb_bug("gc_sweep(): unknown data type 0x%lx(%ld)", obj,

(gdb) print ((RVALUE *)obj)->as->basic
$1 = {flags = 1074907300, klass = 5}

Which is the excpected anomaly.

Here is the relevant backtrace:

#0  obj_free (obj=1074716744) at gc.c:1150
#1  0x40045d59 in gc_sweep () at gc.c:939
#2  0x400463b0 in rb_gc () at gc.c:1299
#3  0x40044ebb in rb_newobj () at gc.c:335
#4  0x40085796 in str_alloc (klass=1074028782) at string.c:45
#5  0x40085973 in str_new3 (klass=1074907300, str=1074848760) at string.c:121
#6  0x40085a05 in rb_str_new3 (str=1074028782) at string.c:136
#7  0x4002ff6f in rb_eval (self=1074911840, n=0x400460ee) at eval.c:3341
#8  0x4002fef1 in rb_eval (self=1074911840, n=0x400460ee) at eval.c:2495
#9  0x40032128 in rb_yield_0 (val=6001, self=1074911840, klass=0, flags=0, avalue=0) at eval.c:4153
#10 0x400325e7 in rb_yield (val=6001) at eval.c:4222
#11 0x40058e50 in int_upto (from=3, to=20000) at numeric.c:1727
#12 0x4003fc76 in call_cfunc (func=0x40058e00 <int_upto>, recv=3, len=1074028782, argc=1, argv=0x4011c8a4) at eval.c:4767
#13 0x40033cb4 in rb_call0 (klass=1074891100, recv=3, id=4305, oid=1074028782, argc=1, argv=0xbfffca30, body=0x401188e4, nosuper=0) at eval.c:4904
#14 0x400344a5 in rb_call (klass=1074891100, recv=3, mid=4305, argc=1, argv=0xbfffca30, scope=0) at eval.c:5122
#15 0x4002f648 in rb_eval (self=1074911840, n=0x400460ee) at ruby.h:626
#16 0x4002e9db in rb_eval (self=1074911840, n=0x400460ee) at eval.c:2717
#17 0x40032128 in rb_yield_0 (val=1074779020, self=1074911840, klass=0, flags=2, avalue=2) at eval.c:4153
#18 0x4003e169 in rb_thread_yield (arg=1074779020, th=0x80adde8) at eval.c:9432
#19 0x4003e004 in rb_thread_start_0 (fn=0x4003e0d0 <rb_thread_yield>, arg=0x400fd38c, th_arg=0x400460ee) at eval.c:9349
#20 0x4003e24a in rb_thread_initialize (thread=1074779040, args=1074779020) at eval.c:9461
#21 0x4003fc76 in call_cfunc (func=0x4003e210 <rb_thread_initialize>, recv=1074779040, len=1074028782, argc=0, argv=0x4011c8a4) at eval.c:4767
#22 0x40033cb4 in rb_call0 (klass=1074894100, recv=1074779040, id=2961, oid=1074028782, argc=0, argv=0x0, body=0x401194b0, nosuper=0) at eval.c:4904
#23 0x400344a5 in rb_call (klass=1074894100, recv=1074779040, mid=2961, argc=0, argv=0x0, scope=1) at eval.c:5122
#24 0x40034828 in rb_funcall2 (recv=36, mid=2961, argc=0, argv=0x0) at ruby.h:626

Hopefully this piece of code will be useful for resolving the bug.