[ruby-core:57678] [ruby-trunk - Bug #8433] Mutexes held by background threads at fork not always released

Issue #8433 has been updated by nobu (Nobuyoshi Nakada).

Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN to 1.9.3: REQUIRED, 2.0.0: REQUIRED


----------------------------------------
Bug #8433: Mutexes held by background threads at fork not always released
https://bugs.ruby-lang.org/issues/8433#change-42298

Author: benweint (Ben Weintraub)
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: ruby 2.0.0p195 (2013-05-14 revision 40734) [x86_64-darwin12.3.0]
Backport: 1.9.3: REQUIRED, 2.0.0: REQUIRED


It appears that the Ruby interpreter attempts to automatically unlock Mutexes held by background threads at the time Process.fork is called in order to avoid deadlocks in the child process. Unfortunately, the logic for doing so appears unreliable.

Reproduction steps:
1. Download the attached mutex_fork.rb
2. Run it

Expected results:
The program should just spin indefinitely, producing no output.

Actual results:
A deadlock is produced, and the following output is seen:

$ ./mutex_fork.rb 
./mutex_fork.rb:14:in `synchronize': No live threads left. Deadlock?	from ./mutex_fork.rb:14:in `block (2 levels) in <main>'
	from ./mutex_fork.rb:13:in `fork'
	from ./mutex_fork.rb:13:in `block in <main>'
	from ./mutex_fork.rb:11:in `loop'
	from ./mutex_fork.rb:11:in `<main>'

Notes:
The child process is deadlocking when attempting to acquire the mutex that was held by a background thread in the parent at the time Process.fork was called. rb_mutex_abandon_all appears to be intended to prevent this problem, but is not reliable as demonstrated by this test case. I suspect that the fork happens after the background thread has acquired the mutex, but before it has updated its keeping_mutexes list, so upon fork, the forking thread does not realize that it should abandon this mutex.

Note that the Mutex#synchronize call on line 12 (just prior to the Process.fork call) is critical to reproduction here. Removing it causes the program to behave correctly.


-- 
http://bugs.ruby-lang.org/