Project

General

Profile

Actions

Bug #2616

closed

unable to trap in doze

Added by rogerdpack (Roger Pack) about 14 years ago. Updated over 12 years ago.

Status:
Closed
Target version:
ruby -v:
-
Backport:
[ruby-core:27625]

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


Files

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

Updated by usa (Usaku NAKAMURA) about 14 years ago

  • 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

Actions #2

Updated by wanabe (_ wanabe) about 14 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

Actions #3

Updated by usa (Usaku NAKAMURA) about 14 years ago

=begin
Hello,

In message "[ruby-core:28641] [Bug #2616] unable to trap in doze"
on Mar.13,2010 22:37:33, 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

=end

Actions #4

Updated by usa (Usaku NAKAMURA) almost 14 years ago

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

=begin

=end

Actions #5

Updated by usa (Usaku NAKAMURA) almost 14 years ago

  • Target version changed from 2.0.0 to 1.9.2

=begin

=end

Actions #6

Updated by usa (Usaku NAKAMURA) almost 14 years ago

  • Due date set to 06/30/2010

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

Actions #7

Updated by wanabe (_ wanabe) almost 14 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

Actions #8

Updated by usa (Usaku NAKAMURA) almost 14 years ago

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

=begin

=end

Actions #9

Updated by mame (Yusuke Endoh) almost 14 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
=end

Actions #10

Updated by mame (Yusuke Endoh) almost 14 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
=end

Updated by nahi (Hiroshi Nakamura) almost 13 years ago

  • Target version changed from 2.0.0 to 1.9.3

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

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

Updated by kosaki (Motohiro KOSAKI) over 12 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.

Actions #14

Updated by kosaki (Motohiro KOSAKI) over 12 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] [ruby-core:27625]

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

Updated by Anonymous over 12 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...

Updated by kosaki (Motohiro KOSAKI) over 12 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0