From: usa@... Date: 2019-08-26T15:39:10+00:00 Subject: [ruby-core:94573] [Ruby master Bug#15360] "ThreadError: deadlock; recursive locking" error when recursive lock shouldn't be possible Issue #15360 has been updated by usa (Usaku NAKAMURA). Backport changed from 2.4: DONTNEED, 2.5: REQUIRED, 2.6: DONE to 2.4: DONTNEED, 2.5: DONE, 2.6: DONE ruby_2_5 r67764 merged revision(s) c1d78a7f0ece2004822193a0c1f1fd3dc38c2fdf. ---------------------------------------- Bug #15360: "ThreadError: deadlock; recursive locking" error when recursive lock shouldn't be possible https://bugs.ruby-lang.org/issues/15360#change-81031 * Author: brockspratlen (Brock Spratlen) * Status: Closed * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin17] * Backport: 2.4: DONTNEED, 2.5: DONE, 2.6: DONE ---------------------------------------- I think I've discovered a Ruby bug, possibly introduced in 2.5. I've attached a reproduction script; running it on Ruby 2.5.0+ (including previews of 2.6.0) seems to always produce a flood of printed `ThreadError: deadlock; recursive locking` exceptions, even though the reproduction code doesn't appear to do any recursive locking. Running the same script on Ruby 2.4.5 doesn't produce any `ThreadError: deadlock; recursive locking` exceptions. I've run the script several times on Ruby 2.4.5, I simply can't reproduce the raising of `ThreadError: deadlock; recursive locking` with this script on 2.4.5. Curiously, removing the `puts e.class` on line 24 causes the bug to go away: `ThreadError: deadlock; recursive locking` never gets raised regardless of which Ruby version I'm running. Given this oddity, I can't help but think the issue is something around writing to stdout. This change in particular looks suspect: https://bugs.ruby-lang.org/issues/9323 Thank you! Brock ---Files-------------------------------- deadlock_test.rb (556 Bytes) -- https://bugs.ruby-lang.org/ Unsubscribe: