Project

General

Profile

Actions

Bug #6575

closed

Thread#kill sets rb_errinfo() to Fixnum 8 after rb_protect(function, data, &error_tag)

Added by ibc (Iñaki Baz Castillo) over 10 years ago. Updated about 10 years ago.

Status:
Rejected
Priority:
Normal
Target version:
ruby -v:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
Backport:
[ruby-core:45567]

Description

Using rb_protect() I've realized that when the thread is killed by other thread using Thread#kill, the error_tag passed to rb_protect() is set to 8 and rb_errinfo() returns Fixnum 8:

ret = rb_protect(function, data, &error_tag);

// While executing function() in Ruby land, our thread is
// killed by Thread.kill.

// If now I inspect rb_errinfo() it returns Fixnum 8, and
// error_tag it's set to integer 8.

Is it the expected behaviour? Wouldn't make more sense rb_errinfo() to return some kind of a new exception ThreadKilledException or whatever instead of Fixnum 8?


Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #5993: Thread.new{ Fiber.new { Thread.exit }.resume }.join で例外Closednagachika (Tomoyuki Chikanaga)02/10/2012Actions

Updated by ibc (Iñaki Baz Castillo) over 10 years ago

Hi, if this is the expected behavior I would really appreciate a confirmation :)

Updated by ko1 (Koichi Sasada) over 10 years ago

Hi,

(2012/06/11 20:27), ibc (Iñaki Baz Castillo) wrote:

Using rb_protect() I've realized that when the thread is killed by other thread using Thread#kill, the error_tag passed to rb_protect() is set to 8 and rb_errinfo() returns Fixnum 8:

ret = rb_protect(function, data, &error_tag);

// While executing function() in Ruby land, our thread is
// killed by Thread.kill.

// If now I inspect rb_errinfo() it returns Fixnum 8, and
// error_tag it's set to integer 8.

Is it the expected behaviour? Wouldn't make more sense rb_errinfo() to return some kind of a new exception ThreadKilledException or whatever instead of Fixnum 8?

I don't have an idea.

Could you show us the complete small example on it?
I want to try on my environment.

Thanks,
Koichi

--
// SASADA Koichi at atdot dot net

Updated by nagachika (Tomoyuki Chikanaga) over 10 years ago

Hi,

Just for reference. r35622 could be related, or ticket #5993 seems related issue.
ibc-san, could you try to reproduce the problem on trunk?

Thanks,

Updated by ibc (Iñaki Baz Castillo) over 10 years ago

BTW, is Ruby-head (ruby 2.0.0dev (2012-06-13 trunk 36062) [x86_64-linux]) stable enough?

Running my C extension (which uses blocking region for running a libuv loop) with 1.9.3-p0 works perfectly, but using 2.0.0dev I get assertion errors due to states that should never happen in my C code. Are there important changes in the blocking-region stuff in 2.0.0?

Updated by naruse (Yui NARUSE) over 10 years ago

  • Status changed from Open to Feedback

nagachika (Tomoyuki Chikanaga) wrote:

Hi,

Just for reference. r35622 could be related, or ticket #5993 seems related issue.
ibc-san, could you try to reproduce the problem on trunk?

The correct fix of it is r35625.
The commit message maybe helps your problem.

Updated by ibc (Iñaki Baz Castillo) over 10 years ago

Thanks, that's more or less the workaround I've applied in my code: if rb_protect() detects an error and rb_errinfo() returns a Fixnum, then I don't raise it, but instead set the error to Interrupt and then raise it.

Updated by mame (Yusuke Endoh) about 10 years ago

  • Status changed from Feedback to Rejected
  • Assignee set to ko1 (Koichi Sasada)

This is not a bug. So I'm closing this ticket.

Because Thread#kill should not be rescue'd so easily, it does throw a special exception which has no class, to make it hard to rescue.

Incidentally, the value 8 means INT2FIX(TAG_FATAL) which is set in rb_threadptr_to_kill:

1690 static void
1691 rb_threadptr_to_kill(rb_thread_t *th)
1692 {
1693 rb_threadptr_async_errinfo_clear(th);
1694 th->status = THREAD_TO_KILL;
1695 th->errinfo = INT2FIX(TAG_FATAL);
1696 TH_JUMP_TAG(th, TAG_FATAL);
1697 }

If you want to know the detailed rationale, please ask ko1 in the mailing list.
If you wish, please open another feature request with the concrete motivation.

--
Yusuke Endoh

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0