Bug #2616

unable to trap in doze

Added by Roger Pack about 5 years ago. Updated over 3 years ago.

[ruby-core:27625]
Status:Closed
Priority:Low
Assignee:Koichi Sasada
ruby -v:- Backport:

Description

=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

th_sigill.patch Magnifier (1005 Bytes) _ wanabe, 03/13/2010 10:37 PM

Associated revisions

Revision 32523
Added by Motohiro KOSAKI over 3 years ago

  • signal.c (sig_trap): don't permit to change a signal handler which the interpreter reserved.
  • signal.c (reserved_signal_p): ditto.
    [Bug #2616]

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

Revision 32523
Added by Motohiro KOSAKI over 3 years ago

  • signal.c (sig_trap): don't permit to change a signal handler which the interpreter reserved.
  • signal.c (reserved_signal_p): ditto.
    [Bug #2616]

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

History

#1 Updated by Usaku NAKAMURA about 5 years ago

  • Status changed from Open to Assigned
  • Assignee set to Usaku NAKAMURA

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

#2 Updated by _ wanabe about 5 years ago

=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

#3 Updated by Usaku NAKAMURA about 5 years ago

=begin
Hello,

In message " [Bug #2616] unable to trap in doze"
on Mar.13,2010 22:37:33, redmine@ruby-lang.org 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 usa@garbagecollect.jp

=end

#4 Updated by Usaku NAKAMURA almost 5 years ago

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

=begin

=end

#5 Updated by Usaku NAKAMURA almost 5 years ago

  • Target version changed from 2.0.0 to 1.9.2

=begin

=end

#6 Updated by Usaku NAKAMURA almost 5 years ago

  • Due date set to 06/30/2010

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

#7 Updated by _ wanabe almost 5 years ago

=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

#8 Updated by Usaku NAKAMURA almost 5 years ago

  • Assignee changed from Usaku NAKAMURA to Koichi Sasada

=begin

=end

#9 Updated by Yusuke Endoh almost 5 years ago

=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 mame@tsg.ne.jp
=end

#10 Updated by Yusuke Endoh almost 5 years ago

  • 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 mame@tsg.ne.jp
=end

#11 Updated by Hiroshi Nakamura almost 4 years ago

  • Target version changed from 2.0.0 to 1.9.3

#12 Updated by Motohiro KOSAKI over 3 years ago

  • Category set to core
  • Priority changed from High to Low
  • 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.

#13 Updated by Motohiro KOSAKI over 3 years ago

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.

#14 Updated by Motohiro KOSAKI over 3 years ago

  • 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]

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

#15 Updated by Anonymous over 3 years ago

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...

#16 Updated by Motohiro KOSAKI over 3 years ago

  • 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.

Also available in: Atom PDF