[ruby-core:68779] [Ruby trunk - Bug #11040] Mutex can be locked by multiple threads, causing Monitor to sometimes hang

Issue #11040 has been updated by Jaap van der Plas.

File mutex_bug.rb added

I attached a slightly simpler test case.

----------------------------------------
Bug #11040: Mutex can be locked by multiple threads, causing Monitor to sometimes hang
https://bugs.ruby-lang.org/issues/11040#change-52057

* Author: Jaap van der Plas
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.3.0dev (2015-04-07 trunk 50178) [x86_64-darwin13]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
I have found a case where Monitor sometimes does not release the lock on its mutex where it should, because the internal counter is increased by another thread than the one holding it. From the trace it seems that `Mutex#lock` succeeds while another thread has not yet unlocked it.

This seems to be triggered when a monitor is accessed by a freshly spawned thread. I have attached a small test case (based on `monitor.rb`) that should trigger the bug reliably and a trace that shows what goes wrong. The most important bits: (showing only `c-return`s from `Mutex#lock` and `Mutex#unlock`)

~~~
...
 #<Thread:0x007fea210a8fd0> c-return mutex_bug.rb:12       lock    Mutex  0
 #<Thread:0x007fea21098c70> c-return mutex_bug.rb:12       lock    Mutex  0
 #<Thread:0x007fea210a8fd0> c-return mutex_bug.rb:22     unlock    Mutex  0
 #<Thread:0x007fea21061450> c-return mutex_bug.rb:12       lock    Mutex #<Thread:0x007fea21098c70> 1
~~~

That last line means that the thread acquired a lock on the mutex, while an owner and count of 1 are already set (ie. it should not be lockable.)

(I first came across this bug on a Rails app when Rack::Timeout seemed to cause requests to hang when logging messages.)

---Files--------------------------------
mutex_bug.rb (1003 Bytes)
mutex_bug_trace.txt (105 KB)
mutex_bug.rb (913 Bytes)


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