[ruby-core:118843] [Ruby master Bug#20670] fork deadlocks in child process due to timer thread
From:
"jhawthorn (John Hawthorn) via ruby-core" <ruby-core@...>
Date:
2024-08-13 20:51:59 UTC
List:
ruby-core #118843
Issue #20670 has been updated by jhawthorn (John Hawthorn).
Status changed from Open to Closed
Backport changed from 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN to 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED
Fixed by https://github.com/ruby/ruby/commit/87a85550edd786665e081b355c6af62c4854b1d7
----------------------------------------
Bug #20670: fork deadlocks in child process due to timer thread
https://bugs.ruby-lang.org/issues/20670#change-109410
* Author: jhawthorn (John Hawthorn)
* Status: Closed
* ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux]
* Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED
----------------------------------------
We've been seeing an occasional failure in the Rails CI related to a test which forks and I managed to reduce it to the following reproduction.
``` ruby
Thread.new do
loop { sleep 0.0001 }
end
1000.times do
pid = fork{}
Process.waitpid(pid)
rescue Exception
Process.kill(:KILL, pid)
raise
end
```
This hangs on Ruby 3.3 and HEAD (_fairly_ reliably), but completes always on Ruby 3.2
In a debugger it seems like the timer thread acquires `vm->ractor.sched.lock` in the parent process just as the process is forking. The child process then ends up stuck inside of `thread_sched_atfork` when trying to acquire the same lock.
I've opened https://github.com/ruby/ruby/pull/11356 with a fix
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/