Issue #9835 has been updated by Eric Wong.


 nobu / ruby-lang.org wrote:
 > As signal is asynchronous, it is not guaranteed essentially?
 
 The problem is a race with the way we defer signal handling
 
 Kyle expected two states for USR1:
 1) print children: sighandler, trap_list[sig].cmd === proc
 2) ignore: SIG_IGN, trap_list[sig].cmd == 0
 
 However, the problem is we queued a SIGUSR1 at 1),
 but queue and handle the signal after 2) passes
 
 So the queued signal hits cmd==0, leading to rb_threadptr_signal_raise
 and SignalException.  Signals queued after 2) are safe from this
 condition.
 
 > Anyway, the patch doesn't seem evil.
 
 OK, I'll wait a bit for Kyle to confirm.  However, I just managed to
 reproduce the issue by limiting to one CPU on one of my machines:
 
 	schedtool -a 0x1 -e ruby test.rb
 
 My proposed patch seems to fix it on my machine.

----------------------------------------
Bug #9835: IGNORE signal handler has possible race condition in Ruby 2.1.2
https://bugs.ruby-lang.org/issues/9835#change-46849

* Author: Kyle Smith
* Status: Rejected
* Priority: Low
* Assignee: 
* Category: core
* Target version: 
* ruby -v: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I'm migrating an application from 1.8.7 to 2.1.1/2.1.2, so I'm not sure when this was introduced.  Attached is a demo program with some notes about how the IGNORE option to Signal.trap seems to have a race condition whereby receiving that signal shortly after that call, it raises a SignalException with the message including only the name of the signal it received.  However, if you trap the signal with an empty block, that race does not occur.

I've tested the attached program on 1.8.7 (no issue), 2.1.1 (issue) and 2.1.2 (issue) on a Linux system (Ubuntu lucid).

---Files--------------------------------
test.rb (1.37 KB)


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