The pthreads changes will most likely result in a deadlock, not segfaults, although segfaults cannot be discounted.  Can you please provide a reproducer that I can try out?

You can execute the failing test case [1] using:

make test-all TESTS="--name /TestThread#test_local_barrier/"

Actually, it just executes the file [2].

And this [3] is the test case which hangs:

make test-all TESTS="--name /TestSetTraceFunc#test_tracepoint_with_multithreads/"



[1] https://github.com/ruby/ruby/blob/ruby_2_2/test/ruby/test_thread.rb#L122
[2] https://github.com/ruby/ruby/blob/ruby_2_2/test/ruby/lbtest.rb
[3] https://github.com/ruby/ruby/blob/ruby_2_2/test/ruby/test_settracefunc.rb#L853

And this error I met today for the first time might be related:

/builddir/build/BUILD/ruby-2.2.2/test/ruby/test_rand.rb:440: [BUG] pthread_cond_destroy: Device or resource busy (EBUSY)
ruby 2.2.2p95 (2015-04-13 revision 50295) [i386-linux]
-- Control frame information -----------------------------------------------
c:0023 p:---- s:0110 e:000109 CFUNC  :start
c:0022 p:0013 s:0107 e:000106 METHOD /builddir/build/BUILD/ruby-2.2.2/test/ruby/test_rand.rb:440
c:0021 p:0038 s:0100 e:000099 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:889
c:0020 p:0069 s:0095 e:000094 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1274
c:0019 p:0019 s:0087 e:000086 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit/testcase.rb:17
c:0018 p:0068 s:0083 e:000082 BLOCK  /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:946 [FINISH]
c:0017 p:---- s:0077 e:000076 CFUNC  :map
c:0016 p:0116 s:0074 e:000073 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:939
c:0015 p:0015 s:0063 e:000061 BLOCK  /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:683 [FINISH]
c:0014 p:---- s:0058 e:000057 CFUNC  :each
c:0013 p:0067 s:0055 E:ffffdaa8 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:681
c:0012 p:0135 s:0049 E:ffffdb30 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:890
c:0011 p:0009 s:0039 E:ffffde4c METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1101
c:0010 p:0009 s:0036 E:ffffdba0 BLOCK  /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1088 [FINISH]
c:0009 p:---- s:0033 e:000032 CFUNC  :each
c:0008 p:0048 s:0030 E:ffffdb68 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1087
c:0007 p:0017 s:0026 E:ffffdbd8 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1075
c:0006 p:0019 s:0022 E:ffffdc10 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:32
c:0005 p:0010 s:0018 E:ffffdc4c METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:800
c:0004 p:0040 s:0013 E:ffffdc7c METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:860
c:0003 p:0013 s:0010 E:ffffdcb0 METHOD /builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:864
c:0002 p:0255 s:0006 E:ffffedf0 EVAL   ./test/runner.rb:40 [FINISH]
c:0001 p:0000 s:0002 E:ffffe9c4 TOP    [FINISH]
-- Ruby level backtrace information ----------------------------------------
./test/runner.rb:40:in `<main>'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:864:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:860:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:800:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:32:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1075:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1087:in `_run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1087:in `each'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1088:in `block in _run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1101:in `run_tests'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:890:in `_run_anything'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:681:in `_run_suites'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:681:in `each'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:683:in `block in _run_suites'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:939:in `_run_suite'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:939:in `map'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:946:in `block in _run_suite'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit/testcase.rb:17:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/minitest/unit.rb:1274:in `run'
/builddir/build/BUILD/ruby-2.2.2/test/lib/test/unit.rb:889:in `run_test'
/builddir/build/BUILD/ruby-2.2.2/test/ruby/test_rand.rb:440:in `test_rand_reseed_on_fork'
/builddir/build/BUILD/ruby-2.2.2/test/ruby/test_rand.rb:440:in `start'
-- C level backtrace information -------------------------------------------
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_print_backtrace+0x27) [0xf763d0d7] vm_dump.c:693
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_vm_bugreport+0x6eb) [0xf763d7db] vm_dump.c:971
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_bug+0x51) [0xf75073e1] error.c:409
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_bug_errno+0x4d) [0xf75074bd] error.c:439
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(native_cond_destroy+0x34) [0xf7642b24] thread_pthread.c:296
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(mutex_free+0x3a) [0xf7643f3a] thread.c:4127
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(gc_sweep_step+0x8fa) [0xf752835a] gc.c:1957
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(gc_sweep+0x39) [0xf75285a9] gc.c:3385
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(gc_start+0x4ae) [0xf7528c6e] gc.c:5205
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(gc_start_internal+0xe6) [0xf75297c6] gc.c:6187
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(call_cfunc_m1+0x1f) [0xf762148f] vm_insnhelper.c:1210
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_cfunc+0x16f) [0xf7626f0f] vm_insnhelper.c:1382
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_method+0x145) [0xf7636a35] vm_insnhelper.c:1691
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec_core+0x118b) [0xf762a8fb] insns.def:1054
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec+0x81) [0xf762f501] vm.c:1400
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(invoke_block_from_c+0x615) [0xf7634ec5] vm.c:813
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_yield+0x70) [0xf7635f80] vm.c:853
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_ary_collect+0x5b) [0xf74c752b] array.c:2695
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(call_cfunc_0+0xf) [0xf76214af] vm_insnhelper.c:1216
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_cfunc+0x16f) [0xf7626f0f] vm_insnhelper.c:1382
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec_core+0x10f1) [0xf762a861] insns.def:1024
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec+0x81) [0xf762f501] vm.c:1400
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(invoke_block_from_c+0x615) [0xf7634ec5] vm.c:813
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_yield+0x70) [0xf7635f80] vm.c:853
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_ary_each+0x54) [0xf74c2264] array.c:1803
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(call_cfunc_0+0xf) [0xf76214af] vm_insnhelper.c:1216
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_cfunc+0x16f) [0xf7626f0f] vm_insnhelper.c:1382
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_method+0x145) [0xf7636a35] vm_insnhelper.c:1691
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec_core+0x10f1) [0xf762a861] insns.def:1024
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec+0x81) [0xf762f501] vm.c:1400
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(invoke_block_from_c+0x615) [0xf7634ec5] vm.c:813
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_yield+0x70) [0xf7635f80] vm.c:853
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_ary_each+0x54) [0xf74c2264] array.c:1803
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(call_cfunc_0+0xf) [0xf76214af] vm_insnhelper.c:1216
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_cfunc+0x16f) [0xf7626f0f] vm_insnhelper.c:1382
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_call_method+0x145) [0xf7636a35] vm_insnhelper.c:1691
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec_core+0x10f1) [0xf762a861] insns.def:1024
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(vm_exec+0x81) [0xf762f501] vm.c:1400
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(rb_iseq_eval_main+0x80) [0xf7631020] vm.c:1670
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(ruby_exec_internal+0xac) [0xf750a3fc] eval.c:252
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(ruby_exec_node+0x25) [0xf750c275] eval.c:317
/builddir/build/BUILD/ruby-2.2.2/libruby.so.2.2.0(ruby_run_node+0x31) [0xf750e261] eval.c:309
/builddir/build/BUILD/ruby-2.2.2/ruby(main+0x69) [0xf774d749] main.c:36

Torvald,

Comment #2 provides a smaller reproducer. I'm curious to know if this is related to bug 1235245? Thoughts?

(In reply to Carlos O'Donell from comment #4)
> Torvald,
> 
> Comment #2 provides a smaller reproducer. I'm curious to know if this is
> related to bug 1235245? Thoughts?

So far, I was able to reproduce the hand mentioned in Comment #2, but not the lbtest.rb failure.  I'm currently trying to figure out whether the use of condvars in those two cases is correct -- I'll probably have to reach out to the Ruby community for help.  The symptoms observed in both cases could be due to incorrect use of condvars, or also due to a bug in the condvar implementation.

rubygem-rerun is occasionally failing with similar symptoms (bug 1239950).

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

I reported the issue upstream. May be they can provide some hints.

(In reply to Vít Ondruch from comment #8)
> I reported the issue upstream. May be they can provide some hints.

Torvald,

I believe your present analysis is that this is a defect in the new cond var algorithm we were testing in Fedora Rawhide?

Could you please update the status here for Fedora?

Moving this back to Rawhide since the new cond var implementation is not in F23 per f23 branch commit c2535df93e59c5b7f65a39a57f7e176f522b04c1 by Siddhesh which removes it from the release. We want to keep testing in Rawhide.

(In reply to Carlos O'Donell from comment #9)
> Moving this back to Rawhide since the new cond var implementation is not in
> F23

Interesting ... I appreciate the revert ... going to give it a try.

Yes, currently I believe this is an issue in the new cond var implementation.  It's been removed from F23 by Siddhesh; I'm not sure whether he also removed it from rawhide, but it should be.  I haven't completed the fix yet, which we want to test further in rawhide once it's finished.

(In reply to Torvald Riegel from comment #11)
> Yes, currently I believe this is an issue in the new cond var
> implementation.  It's been removed from F23 by Siddhesh; I'm not sure
> whether he also removed it from rawhide, but it should be.  I haven't
> completed the fix yet, which we want to test further in rawhide once it's
> finished.

I have left it in rawhide to shake out any additional issues it may have.  That way, each such report can retest with your new algorithm when we include it and verify if their problem is fixed.

(In reply to Siddhesh Poyarekar from comment #12)
> (In reply to Torvald Riegel from comment #11)
> > Yes, currently I believe this is an issue in the new cond var
> > implementation.  It's been removed from F23 by Siddhesh; I'm not sure
> > whether he also removed it from rawhide, but it should be.  I haven't
> > completed the fix yet, which we want to test further in rawhide once it's
> > finished.
> 
> I have left it in rawhide to shake out any additional issues it may have. 
> That way, each such report can retest with your new algorithm when we
> include it and verify if their problem is fixed.

Agreed.

So how about reverting the patch in Rawhide as well? It is not necessary to test it again and again that it doesn't work reliably, unless there is some new build.

This is still an issue as of glibc-2.22.90-11.fc24. I still observe deadlocks and segfaults during execution of Ruby's test suite and several others. You can observe the packages in Koschei:

https://apps.fedoraproject.org/koschei/package/ruby
https://apps.fedoraproject.org/koschei/package/rubygem-ethon
https://apps.fedoraproject.org/koschei/package/rubygem-typhoeus

(In reply to Vít Ondruch from comment #15)
> This is still an issue as of glibc-2.22.90-11.fc24. I still observe
> deadlocks and segfaults during execution of Ruby's test suite and several
> others. You can observe the packages in Koschei:
> 
> https://apps.fedoraproject.org/koschei/package/ruby
> https://apps.fedoraproject.org/koschei/package/rubygem-ethon
> https://apps.fedoraproject.org/koschei/package/rubygem-typhoeus

We are going to drop the patch from rawhide. Sorry for the delay and thanks for letting us collect a little more data with the patch applied.

(In reply to Carlos O'Donell from comment #16)
> We are going to drop the patch from rawhide. Sorry for the delay and thanks
> for letting us collect a little more data with the patch applied.

Thanks, I appreciate that.

Fixed in commit dd0aad2bf0e54beec4c23d3ddbc2840e3af8f505.