From: benweint@... Date: 2014-10-28T19:03:31+00:00 Subject: [ruby-core:65952] [ruby-trunk - Bug #10443] Forking with contended mutex held can lead to deadlock in child process upon unlock Issue #10443 has been updated by Ben Weintraub. File rb-mutex-unlock-fork-test.rb added The original test case was not actually minimal (there's no need to attempt to re-acquire the lock in the forked child process in order to demonstrate the issue), so I'm attaching an updated version. ---------------------------------------- Bug #10443: Forking with contended mutex held can lead to deadlock in child process upon unlock https://bugs.ruby-lang.org/issues/10443#change-49688 * Author: Ben Weintraub * Status: Open * Priority: Normal * Assignee: * Category: * Target version: * ruby -v: ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-darwin13.0] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- If a Ruby thread calls Process.fork while holding a Mutex (for example, within a Mutex#synchronize block) that is also concurrently being contended for by a background thread, the thread in the child process will occasionally be unable to unlock the mutex it was holding at the time of the fork, and will hang under rb_mutex_unlock_th when attempting to acquire mutex->lock. I've been able to reproduce this on Ruby 2.1.1 - 2.1.3 and 2.2.0-preview1 (haven't tried elsewhere yet). The attached test case demonstrates the issue, although it can take up to 20 minutes to hit a reproducing case. The test case will print one '.' each time it forks. Once it stops printing dots, it has hit this bug (the parent process is stuck in a call to Process.wait, and the child is stuck in rb_mutex_unlock_th). The test case consists of a global lock that is contended for by 10 background threads, in addition to the main thread, which acquires it, forks, and then releases it. ---Files-------------------------------- rb-mutex-unlock-fork-test.rb (372 Bytes) rb-mutex-unlock-fork-test.rb (339 Bytes) -- https://bugs.ruby-lang.org/