Issue #18048 has been updated by nagachika (Tomoyuki Chikanaga).

Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: REQUIRED to 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: DONE

The changesets 050a89543952a2c9e7c9bc938f4fdb538f6c9278, 57eaa07ba6c1ee958c16d5c451e2dceb2208edf1, edbe0e224c2594b7a7b055f0986cbfd690d754d5 and 2d4f29e77e883c29e35417799f8001b8046cde03 are backported by merging https://github.com/ruby/ruby/pull/4686.

----------------------------------------
Bug #18048: Thread#join can break with fiber scheduler unblock fails or blocks.
https://bugs.ruby-lang.org/issues/18048#change-93841

* Author: ioquatix (Samuel Williams)
* Status: Closed
* Priority: Normal
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: DONE
----------------------------------------
In addition to https://bugs.ruby-lang.org/issues/17666 we found several more cases that need to be addressed.

Fix potential hang when joining threads.

If the thread termination invokes user code after `th->status` becomes
`THREAD_KILLED`, and the user unblock function causes that `th->status` to
become something else (e.g. `THREAD_RUNNING`), threads waiting in
`thread_join_sleep` will hang forever. We move the unblock function call
to before the thread status is updated, and allow threads to join as soon
as `th->value` becomes defined.

Wake up join list within thread EC context. (#4471)

If `rb_fiber_scheduler_unblock` raises an exception, it can result in a
segfault if `rb_threadptr_join_list_wakeup` is not within a valid EC. This
change moves `rb_threadptr_join_list_wakeup` into the thread's top level EC
which initially caused an infinite loop because on exception will retry. We
explicitly remove items from the thread's join list to avoid this situation.

These are already fixed on master branch. Here is a PR for backport: https://github.com/ruby/ruby/pull/4686



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>