Bug #15360
closed"ThreadError: deadlock; recursive locking" error when recursive lock shouldn't be possible
Description
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
Updated by brockspratlen (Brock Spratlen) almost 6 years ago
- ruby -v changed from 2.5.3 to ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin17]
Updated by brockspratlen (Brock Spratlen) almost 6 years ago
- Description updated (diff)
Updated by Anonymous over 5 years ago
Is there a plan to fix this? We have been noticing this bug occasionally in production.
Updated by wanabe (_ wanabe) over 5 years ago
git bisect
shows the problem occurs frequently since r58604.
But I don't know it can occur before the commit.
https://bugs.ruby-lang.org/projects/ruby-trunk/repository/trunk/revisions/66489/entry/thread_sync.c#L267
do_mutex_lock()
releases GVL with native_sleep(th, timeout)
.
The mutex may be released and the thread may be interrupted around the same time.
If so, RUBY_VM_CHECK_INTS_BLOCKING(th->ec)
will raise an exception, after locking mutex.
Updated by nbh (nbh _) over 5 years ago
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- Related to Bug #15508: Mutex recursive lock error when combined with Thread#raise added
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- Related to Bug #15645: It is possible to escape `Mutex#synchronize` without releasing the mutex added
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- Status changed from Open to Closed
- Backport changed from 2.4: UNKNOWN, 2.5: UNKNOWN to 2.4: DONTNEED, 2.5: REQUIRED, 2.6: REQUIRED
Fix committed at c1d78a7f0ece2004822193a0c1f1fd3dc38c2fdf
Updated by nagachika (Tomoyuki Chikanaga) over 5 years ago
- Backport changed from 2.4: DONTNEED, 2.5: REQUIRED, 2.6: REQUIRED to 2.4: DONTNEED, 2.5: REQUIRED, 2.6: DONE
ruby_2_6 r67728 merged revision(s) c1d78a7f0ece2004822193a0c1f1fd3dc38c2fdf.
Updated by usa (Usaku NAKAMURA) about 5 years ago
- 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.