Inconsistent SIGIOT failure with thread_safe 0.3.5 test suite

[graaff]

When running the test suite for thread_safe 0.3.5 I'm seeing either a clean run with all tests passing, or the process crashes with an SIGIOT failure. I'm currently testing with ruby 2.0.0p645 (2015-04-13 revision 50299) [x86_64-linux]. Here's the output from a SIGIOT crash.

Run options: --seed 24275

# Running:

TestSynchronizedDelegator ...
TestArray .
TestCacheTorture .../var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/non_concurrent_cache_backend.rb:12: [BUG] Segmentation fault
ruby 2.0.0p645 (2015-04-13 revision 50299) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0010 p:0011 s:0057 e:000056 METHOD /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/non_concurrent_cache_backend.rb:12
c:0009 p:0009 s:0053 e:000052 METHOD /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/mri_cache_backend.rb:26
c:0008 p:0015 s:0048 e:000047 METHOD /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/cache.rb:74
c:0007 p:0058 s:0041 e:000040 METHOD /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:355
c:0006 p:0067 s:0030 e:000029 BLOCK  /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:384 [FINISH]
c:0005 p:---- s:0026 e:000025 CFUNC  :times
c:0004 p:0027 s:0023 e:000022 METHOD /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:378
c:0003 p:0074 s:0014 e:000013 METHOD /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:340
c:0002 p:0026 s:0004 e:000003 BLOCK  /var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:327 [FINISH]
c:0001 p:---- s:0002 e:000001 TOP    [FINISH]

-- Ruby level backtrace information ----------------------------------------
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:327:in `block (2 levels) in run_thread_loop'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:340:in `setup_sync_and_start_loop'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:378:in `_add_remove_loop_outer_multiple_keys'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:378:in `times'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:384:in `block in _add_remove_loop_outer_multiple_keys'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/test/test_cache_loops.rb:355:in `_add_remove_loop_inner_multiple_keys'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/cache.rb:74:in `put_if_absent'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/mri_cache_backend.rb:26:in `compute_if_absent'
/var/tmp/portage/dev-ruby/thread_safe-0.3.5/work/ruby20/thread_safe-0.3.5/lib/thread_safe/non_concurrent_cache_backend.rb:12:in `[]'

-- C level backtrace information -------------------------------------------
/usr/lib64/libruby20.so.2.0(+0x17655b) [0x7fdc7d9bd55b] vm_dump.c:652
/usr/lib64/libruby20.so.2.0(+0x646da) [0x7fdc7d8ab6da] error.c:288
/usr/lib64/libruby20.so.2.0(rb_bug+0xb3) [0x7fdc7d8abde3] error.c:307
/usr/lib64/libruby20.so.2.0(+0x110914) [0x7fdc7d957914] signal.c:691
/lib64/libc.so.6(+0x34ee0) [0x7fdc7d4e3ee0] array.c:2327
/usr/lib64/libruby20.so.2.0(+0x11830c) [0x7fdc7d95f30c] st.c:388
/usr/lib64/libruby20.so.2.0(st_lookup+0xdd) [0x7fdc7d95f9ad] st.c:430
/usr/lib64/libruby20.so.2.0(rb_hash_aref+0x1f) [0x7fdc7d8c6b3f] hash.c:574
/usr/lib64/libruby20.so.2.0(+0x1650c4) [0x7fdc7d9ac0c4] insns.def:1835
/usr/lib64/libruby20.so.2.0(+0x168453) [0x7fdc7d9af453] vm.c:1270
/usr/lib64/libruby20.so.2.0(rb_yield+0x6a0) [0x7fdc7d9b7df0] vm.c:716
/usr/lib64/libruby20.so.2.0(+0xa5b5e) [0x7fdc7d8ecb5e] numeric.c:3612
/usr/lib64/libruby20.so.2.0(+0x1604d4) [0x7fdc7d9a74d4] vm_insnhelper.c:1513
/usr/lib64/libruby20.so.2.0(+0x163bed) [0x7fdc7d9aabed] insns.def:1002
/usr/lib64/libruby20.so.2.0(+0x168453) [0x7fdc7d9af453] vm.c:1270
/usr/lib64/libruby20.so.2.0(+0x16b2c6) [0x7fdc7d9b22c6] vm.c:716
/usr/lib64/libruby20.so.2.0(+0x16b8f6) [0x7fdc7d9b28f6] vm.c:764
/usr/lib64/libruby20.so.2.0(+0x16b93a) [0x7fdc7d9b293a] vm.c:783
/usr/lib64/libruby20.so.2.0(+0x17dbd3) [0x7fdc7d9c4bd3] thread.c:514
/usr/lib64/libruby20.so.2.0(+0x17dd80) [0x7fdc7d9c4d80] thread_pthread.c:765
/lib64/libpthread.so.0(+0x8224) [0x7fdc7d098224]
/lib64/libc.so.6(clone+0x6d) [0x7fdc7d59645d] rational.c:653

[thedarkone]

Thanks for reporting this. thread_safe is pure Ruby when running on MRI, so this an MRI bug, technically this belongs on https://bugs.ruby-lang.org/. Reproducing and narrowing it down is probably going to be difficult :(.

[graaff]

Yes, I was afraid that this was the case, given there is no extension code in thread_safe. I was hoping this would ring a bell for you :-)

I found https://bugs.ruby-lang.org/issues/9649 which seems to be the same issue, but claims that it is fixed. I've added a comment.

[jdantonio]

@graaff I'm sorry this has been a problem for you, but it doesn't sound like we can do anything. Can I close this issue?

[graaff]

Yes, let's close this. I got a response on the upstream bug so I'll continue there. Thanks!