Project

General

Profile

Actions

Bug #17587

closed

Segmentation fault with ractors and unix signals

Added by mweitzel (Matthew Weitzel) about 3 years ago. Updated over 2 years ago.

Status:
Rejected
Target version:
-
ruby -v:
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin19]
[ruby-core:102269]

Description

Segmentation fault when trapping signals and using a Ractor.

Can be reproduced by running the following

Ractor.new do
  Signal.trap('INT') do
    Ractor.yield("yoo hoO! big summer blowout")
  end
  `kill -2 #{$$}`
  `kill -2 #{$$}`
  `kill -2 #{$$}`
end.take

Files

Updated by ko1 (Koichi Sasada) about 3 years ago

  • Assignee set to ko1 (Koichi Sasada)

current master is stuck.
I'll check it.

Updated by wanabe (_ wanabe) about 3 years ago

The current behavior of stacking appears to be as expected.

The registered signal handler is called from the main thread. https://git.ruby-lang.org/ruby.git/tree/thread.c?id=947d93b715436b13eefa39f87737bdad3c1f870a#n2430
Ractor.yield in the main thread must cause stuck because there are no Ractor to take it in parallel.
In addition, signals are basically ignored in the signal handler, because of interrupt_mask. https://bugs.ruby-lang.org/issues/6009
For example, Signal.trap("USR2") do sleep end; Process.kill(:USR2, $$) can make ruby stuck.

I guess this is normal behavior that has nothing to do with Ractor.
(However, there is still room for consideration of safe behavior when a signal is received in a signal handler.)

Actions #3

Updated by hsbt (Hiroshi SHIBATA) over 2 years ago

  • Status changed from Open to Assigned

Updated by ko1 (Koichi Sasada) over 2 years ago

  • Status changed from Assigned to Rejected

as @wanabe (_ wanabe) san described, it is an expected behavior.
(I'm not sure why I prohibited trap in Ractor...)

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0