Description of problem: Ruby test suite randomly core dumps since glibc-2.22.90-16.fc24 with message: test_thread.rb .............................................E.... #1006 test_thread.rb:390:in `<top (required)>': core dumped FAIL 1/1010 tests failed uncommon.mk:549: recipe for target 'yes-btest-ruby' failed make: *** [yes-btest-ruby] Error 1 This is the source code of the offending test: https://github.com/ruby/ruby/blob/v2_2_3/bootstraptest/test_thread.rb You can observe the issues in Koschei [1]. Version-Release number of selected component (if applicable): $ rpm -q glibc glibc-2.22.90-16.fc24.x86_64 $ rpm -q ruby ruby-2.2.3-44.fc24.x86_64 How reproducible: Randomly Steps to Reproduce: 1. make btest TESTOPTS="--sets=thread" 2. 3. Actual results: Expected results: Additional info: [1] https://apps.fedoraproject.org/koschei/package/ruby
The precise link to source code should be: https://github.com/ruby/ruby/blob/v2_2_3/bootstraptest/test_thread.rb#L390
(In reply to Vít Ondruch from comment #1) > The precise link to source code should be: > > https://github.com/ruby/ruby/blob/v2_2_3/bootstraptest/test_thread.rb#L390 Thanks. Would you please provide instructions how to run this test in isolation?
(In reply to Florian Weimer from comment #2) > Thanks. Would you please provide instructions how to run this test in > isolation? > Steps to Reproduce: > 1. make btest TESTOPTS="--sets=thread" This is as isolated as it is possible. If you really want to run just the tiniest part of the code just with the specific part of the code, I am afraid you have to modify the file. And just one additional remark, I have not been successful in reproducing this issue locally so far (I am running the test locally 500 times right now). Not sure what might be the difference in Koji environment, since there is apparently higher chance to hit this issue.
Created attachment 1093634 [details] ABRT's core dump Ok, in less then 1000 iteration, I was able to reproduce the issue locally. Please see the attached core dump caught by ABRT.
This assert fires: 821 /* Arenas on the free list are not attached to any thread. */ 822 assert (result->attached_threads == 0); I don't know yet why this supposed invariant is broken.
A possible explanation: reused_arena picks an arena on the free list which was added to it after the initial check in arena_get2. There is no locking which prevents that, and arenas on the free list are not removed from the circular arena list around main_arena. This is definitely a bug. I don't know if it is this bug, though.
I have a very reliable test case, just needs some polishing.
This is still unresolved as of glibc-2.22.90-24.fc24. This is recent build failure in Koschei: https://apps.fedoraproject.org/koschei/build/1153943
(In reply to Vít Ondruch from comment #8) > This is still unresolved as of glibc-2.22.90-24.fc24. This is recent build > failure in Koschei: > > https://apps.fedoraproject.org/koschei/build/1153943 Yes, this is expected. The upstream patch still hasn't been reviewed. I expect some movement there this week. If not, I will back out the patch in rawhide which causes this regression.
thx for the update.
Finally fixed in rawhide (release branches were not affected). Sorry for the delay.