Bug #6416
Deadlock when calling Thread#join from signal interrupt context
Description
=begin
The interpreter can deadlock when calling Thread#join both from the main context and from the signal handler context.
t = Thread.new{ sleep 3 }
Signal.trap "SIGINT" do
t.join
end
puts 'Press ctrl + c now'
t.join
The above will deadlock on linux x86_64 with ruby 1.9.x and ruby trunk. It works fine with ruby 1.8.7-p352 and JRuby.
=end
Associated revisions
- vm_core.h (rb_thread_struct): added 'in_trap' member for marking running trap handler.
- signal.c (signal_exec): turn on in_trap when running trap.
- thread.c (Init_Thread, thread_create_core): initialize in_trap when creating new threads.
- thread.c (thread_join_m): raise ThreadError when running trap handler.Bug [#6416][ruby-core:44956]
- test/ruby/test_thread.rb (test_thread_join_in_trap): new test for the above.
- vm_core.h (rb_thread_struct): added 'in_trap' member for marking running trap handler.
- signal.c (signal_exec): turn on in_trap when running trap.
- thread.c (Init_Thread, thread_create_core): initialize in_trap when creating new threads.
- thread.c (thread_join_m): raise ThreadError when running trap handler.Bug [#6416][ruby-core:44956]
- test/ruby/test_thread.rb (test_thread_join_in_trap): new test for the above.
- vm_core.h (rb_thread_struct): added 'in_trap' member for marking running trap handler.
- signal.c (signal_exec): turn on in_trap when running trap.
- thread.c (Init_Thread, thread_create_core): initialize in_trap when creating new threads.
- thread.c (thread_join_m): raise ThreadError when running trap handler.Bug [#6416][ruby-core:44956]
- test/ruby/test_thread.rb (test_thread_join_in_trap): new test for the above.
- vm_core.h (rb_thread_struct): added 'in_trap' member for marking running trap handler.
- signal.c (signal_exec): turn on in_trap when running trap.
- thread.c (Init_Thread, thread_create_core): initialize in_trap when creating new threads.
- thread.c (thread_join_m): raise ThreadError when running trap handler.Bug [#6416][ruby-core:44956]
- test/ruby/test_thread.rb (test_thread_join_in_trap): new test for the above.
- vm_core.h (rb_thread_struct): added 'in_trap' member for marking running trap handler.
- signal.c (signal_exec): turn on in_trap when running trap.
- thread.c (Init_Thread, thread_create_core): initialize in_trap when creating new threads.
- thread.c (thread_join_m): raise ThreadError when running trap handler.Bug [#6416][ruby-core:44956]
- test/ruby/test_thread.rb (test_thread_join_in_trap): new test for the above.
- vm_core.h (rb_thread_struct): added 'in_trap' member for marking running trap handler.
- signal.c (signal_exec): turn on in_trap when running trap.
- thread.c (Init_Thread, thread_create_core): initialize in_trap when creating new threads.
- thread.c (thread_join_m): raise ThreadError when running trap handler.Bug [#6416][ruby-core:44956]
- test/ruby/test_thread.rb (test_thread_join_in_trap): new test for the above.
History
Updated by mame (Yusuke Endoh) about 7 years ago
Updated by - Status changed from Open to Assigned
- Assignee set to kosaki (Motohiro KOSAKI)
Kosaki-san, could you take a look?
--
Yusuke Endoh mame@tsg.ne.jp
Updated by kosaki (Motohiro KOSAKI) about 7 years ago
Updated by - Assignee changed from kosaki (Motohiro KOSAKI) to ko1 (Koichi Sasada)
Hi ko1,
This is because thread_join() is not designed reentrant. It can insert a thread twice join_list. And then, join_list
is going to become circular ring and it lead to deadlock.
So, I think th.join in trap context should raise ThreadError. What do you think?
Updated by
Updated by ko1 (Koichi Sasada) over 6 years ago
- Assignee changed from ko1 (Koichi Sasada) to kosaki (Motohiro KOSAKI)
I agree with kosaki-san's comment.
Updated by kosaki (Motohiro KOSAKI) over 6 years ago
- Status changed from Assigned to Closed
Fixed at r37852.
Thanks, Timothy!
Updated by authorNari (Narihiro Nakamura) over 6 years ago
Updated by Hello
I need sometimes to call Thread#join in Signal.trap when I want to implement safe termination in a server.
For instance: https://gist.github.com/4158509
Is it a wrong use case in the first place?
Thanks.
Updated by kosaki (Motohiro KOSAKI) over 6 years ago
Nari,
In your case, main thread and trap handler uses the same mutex and it is racy and deadlockable. Even if I revert my change, it wouldn't work.
Updated by authorNari (Narihiro Nakamura) over 6 years ago
kosaki (Motohiro KOSAKI) wrote:
Nari,
In your case, main thread and trap handler uses the same mutex and it is racy and deadlockable. Even if I revert my change, it wouldn't work.
I see, Thanks!
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@37852 b2dd03c8-39d4-4d8f-98ff-823fe69b080e