Issue #6634 has been updated by mame (Yusuke Endoh).

File lol2.rb added
Status changed from Feedback to Assigned
Assignee set to kosaki (Motohiro KOSAKI)
Target version set to 2.0.0

I succeeded to reproduce the issue, by adding set_trace_func to lol.rb, redirecting the output to the file, and repeating the invocation until the error occurs.
It looks very very timing sensitive issue.

    $ gem install threadpool

    $ ./ruby -v
    ruby 2.0.0dev (2012-11-05 trunk 37474) [x86_64-linux]

    $ ruby -e 'loop { system("./ruby lol2.rb > t") || break }'
    /home/mame/work/local/lib/ruby/gems/2.0.0/gems/threadpool-0.1.2/lib/threadpool.rb:183:in `join': No live threads left. Deadlock?
            from /home/mame/work/local/lib/ruby/gems/2.0.0/gems/threadpool-0.1.2/lib/threadpool.rb:183:in `join'
            from lol.rb:9:in `<main>'

    $ ruby -e 'loop { system("./ruby lol2.rb > t") || break }'
    <internal:prelude>:8:in `lock': deadlock; recursive locking (ThreadError)
            from <internal:prelude>:8:in `synchronize'
            from /home/mame/work/local/lib/ruby/2.0.0/thread.rb:69:in `wait'
            from /home/mame/work/local/lib/ruby/gems/2.0.0/gems/threadpool-0.1.2/lib/threadpool.rb:234:in `block (3 levels) in spawn_thread'
            from <internal:prelude>:10:in `synchronize'
            from /home/mame/work/local/lib/ruby/gems/2.0.0/gems/threadpool-0.1.2/lib/threadpool.rb:222:in `block (2 levels) in spawn_thread'
            from /home/mame/work/local/lib/ruby/gems/2.0.0/gems/threadpool-0.1.2/lib/threadpool.rb:249:in `loop'
            from /home/mame/work/local/lib/ruby/gems/2.0.0/gems/threadpool-0.1.2/lib/threadpool.rb:249:in `block in spawn_thread'

I reviewed the source of threadpool gem, but I could find no problem.
Precisely, it may attempt to call undefined method named "reason"; it is clearly irrelevant.

Kosaki-san, could you try to reproduce?  The core behavior looks to me indeed strange (too subtle to explain in English, sorry), but I failed to find the bug.


????????????????
????????????? (???????????? 100 ???????? 1 ????????????) ???gdb ???使????????????????? printf debug ?????????????????????確????? core ??????????????????????????????????????????????
CV ?????? mutex ??? lock ???????????????????? threadpool ?????? mutex ??? lock ????????????????????????????????????????????
大???????????????????????????? (GC issue ????????????????????) ??????????????????????????????????????????????????????試??????????????????????????????????

-- 
Yusuke Endoh <mame / tsg.ne.jp>
----------------------------------------
Bug #6634: Deadlock with join and ConditionVariable
https://bugs.ruby-lang.org/issues/6634#change-32435

Author: meh. (meh. I don't care)
Status: Assigned
Priority: Normal
Assignee: kosaki (Motohiro KOSAKI)
Category: core
Target version: 2.0.0
ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]


I'm getting a fatal deadlock in one of my gems, it's a simple threadpool implementation.

The library works both in Rubinius and JRuby, so I guess it's a bug.

The gem is here: https://github.com/meh/ruby-threadpool

The example that crashes is attached.

Basically it raises a fatal deadlock if you join a thread and then call ConditionVariable#wait, I'm not 100% sure if the bug is in the ConditionVariable or what, all I know is that it happens in that situation and that it works on Rubinius and JRuby.


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