Bug #2616: unable to trap in doze

• Status: Closed
• Assignee: ko1 (Koichi Sasada)
• Target version: 2.0.0
• ruby -v: -

[rogerdpack (Roger Pack)]

=begin
this snippet:

trap("ILL") { puts 'got one' }
Thread.new { sleep 0.1;Process.kill "ILL", Process.pid}
sleep

appears to work like a champ in 1.8, and fail for 1.9.x
=end

[usa (Usaku NAKAMURA)]

• Status changed from Open to Assigned
• Assignee set to usa (Usaku NAKAMURA)

=begin
signals to myself which mapped to SEH seems to be ignored...
Of course, this is a bug.
=end

[wanabe (_ wanabe)]

• File th_sigill.patch th_sigill.patch added

=begin
I guess SIGILL is reset in child thread.
I wrote a patch, but this validity is very doubtful.
I'd appreciate anyone to correct the patch.
=end

[usa (Usaku NAKAMURA)]

=begin
Hello,

In message "[ruby-core:28641] [Bug #2616] unable to trap in doze"
on Mar.13,2010 22:37:33, [e-mail] wrote:

I guess SIGILL is reset in child thread.
I wrote a patch, but this validity is very doubtful.
I'd appreciate anyone to correct the patch.

With this patch, re-defining the signal handler on another thread
(such as main thread), each threads has another handler, doesn't
it?

I think that all child threads should define handlers for SEH'ed
signals to redirect the signals to main thread.

Regards,

U.Nakamura [e-mail]

=end

[usa (Usaku NAKAMURA)]

• Priority changed from Normal to 5
• Target version set to 2.0.0

=begin

=end

[usa (Usaku NAKAMURA)]

• Target version changed from 2.0.0 to 1.9.2

=begin

=end

[usa (Usaku NAKAMURA)]

• Due date set to 06/30/2010

=begin
wanabe-san, do you still track this problem?
=end

[wanabe (_ wanabe)]

=begin

wanabe-san, do you still track this problem?

No. I wanted to write a patch, but I couldn't.
This problem is too difficult for me. Sorry.
=end

[usa (Usaku NAKAMURA)]

• Assignee changed from usa (Usaku NAKAMURA) to ko1 (Koichi Sasada)

=begin

=end

[mame (Yusuke Endoh)]

=begin
Hi, ko1

This ticket is somehow assigned to you.
Do you have any idea to fix this issue?

If not, I, as an assistant release manager, determine this as
WONTFIX for 1.9.2.

--
Yusuke Endoh [e-mail]
=end

[mame (Yusuke Endoh)]

• Target version changed from 1.9.2 to 2.0.0

=begin
No response. This won't be fixed in 1.9.2.

--
Yusuke Endoh [e-mail]
=end

[nahi (Hiroshi Nakamura)]

• Target version changed from 2.0.0 to 1.9.3

[kosaki (Motohiro KOSAKI)]

• Category set to core
• Priority changed from 5 to 3
• Target version changed from 1.9.3 to 2.0.0

This issue need to be rewritten signal related code widely and SIGILL isn't so much important on practical application.
Therefore I'll change target version.

[kosaki (Motohiro KOSAKI)]

For clarification, now SIGFPE, SIGILL and SIGSEGV can't be trapped from ruby script if you have multi threads and use windows.
but I don't think it's big matter.

[kosaki (Motohiro KOSAKI)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r32523.
Roger, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

• signal.c (sig_trap): don't permit to change a signal handler which
  the interpreter reserved.

• signal.c (reserved_signal_p): ditto.
  [Bug #2616] [ruby-core:27625]

• test/ruby/test_signal.rb (TestSignal#test_reserved_signal):
  added a test for reserved signal.

For clarification, now SIGFPE, SIGILL and SIGSEGV can't be trapped from ruby script if you have multi threads and use windows.
but I don't think it's big matter.

Agreed--nobody seems to have noticed it but myself until now...

[kosaki (Motohiro KOSAKI)]

• ruby -v changed from ruby 1.9.2dev (2010-01-06 trunk 26246) [i386-mingw32] to -

For clarification, now SIGFPE, SIGILL and SIGSEGV can't be trapped from ruby script if you have multi threads and use windows.
but I don't think it's big matter.

Agreed--nobody seems to have noticed it but myself until now...

The point is, this issue is not mere bug. It's YARV core design issue.
As you know, ruby 1.9 can have multi threads. But many script don't
have proper multi thread safe trap code. Thus we decided always execute
trap hander by main thread. But, synchronous signal (e.g. SIGSEGV, SIGILL)
can't be delivered to other threads. It's synchronous.

Therefore, I'm planning to don't permit to use trap of synchrounous signal since
1.9.4 or later. Of course, every comments are welcome.

Thanks.