Bug #20638: Threads not collected by GC under RUBY_MN_THREADS=1

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[jhawthorn (John Hawthorn)]

When running with RUBY_MN_THREADS=1 I noticed increased memory usage when creating many threads. It seems like Threads aren't able to be collected when run concurrently.

$ ruby -e '500.times { 50.times.map { Thread.new{} }.map(&:join) }; sleep 1; GC.start; p ObjectSpace.each_object(Thread).count'
1

$ RUBY_MN_THREADS=1 ruby -e '500.times { 50.times.map { Thread.new{} }.map(&:join) }; sleep 1; GC.start; p ObjectSpace.each_object(Thread).count'
24501

(Note that 24500 is 500 * 49. It seems like each time we make the 50 concurrent threads 49 of them leak)

I tested both on macos and linux and this occurs both on Ruby 3.3 and head. No combination of sleeping or GC seems to clear them.

According to a heap dump these are being held in memory by the VM root.

[jhawthorn (John Hawthorn)]

• Status changed from Open to Closed

Applied in changeset git|1cf32b2d7f2bb0dafce6108ecfc496491b19ad8a.

---

Fix threads stuck as zombie under M:N

In this case thread_sched_switch0 never returns, so we would never
end up setting finished to true.

Fixes [Bug #20638]