- ruby-core - ml.ruby-lang.org

[ruby-core:123314] [Ruby Bug#21613] TestGc#test_exception_in_finalizer_procs and TestGc#test_exception_in_finalizer_method fail with ASAN
by Eregon (Benoit Daloze) 21 Sep '25

21 Sep '25

Issue #21613 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21613: TestGc#test_exception_in_finalizer_procs and TestGc#test_exception_in_finalizer_method fail with ASAN https://bugs.ruby-lang.org/issues/21613 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- See https://github.com/ruby/ruby-dev-builder/actions/runs/17883721287/job/50854… ``` 1) Failure: TestGc#test_exception_in_finalizer_procs [/home/runner/work/ruby-dev-builder/ruby-dev-builder/test/ruby/test_gc.rb:828]: pid 40237 exit 0. 1. [1/2] Assertion for "stdout" | <["c1", "c2"]> expected but was | <["c1"]>. 2) Failure: TestGc#test_exception_in_finalizer_method [/home/runner/work/ruby-dev-builder/ruby-dev-builder/test/ruby/test_gc.rb:848]: pid 40260 exit 0. 1. [1/2] Assertion for "stdout" | <["c1", "c2"]> expected but was | <["c1"]>. Finished tests in 630.155129s, 46.2553 tests/s, 9737.2404 assertions/s. 29148 tests, 6135972 assertions, 2 failures, 0 errors, 178 skips ``` Oddly enough https://ci.rvm.jp/results/trunk_asan@ruby-sp1 doesn't fail. This is not the first time, it's been many times that job found issues not caught in ruby/ruby CI, so I would like to request adding a ASAN GHA job doing the same as https://github.com/ruby/ruby-dev-builder in ruby/ruby so such failures are found earlier and do not block ruby-dev-builder and setup-ruby. If not, I will be forced to drop ASAN support in setup-ruby. For now I will exclude these tests on ASAN to unblock, but it's a bit hacky because there seems to be no predicate to detect ASAN, except `Thread.asan?` with `require '-test-/stack'` (= hacky). -- https://bugs.ruby-lang.org/

1 1

[ruby-core:123311] Re: Revised Paperwork.pdf
by Ruby-core 19 Sep '25

19 Sep '25

1 0

[ruby-core:123310] Re: Revised Paperwork.pdf
by Ruby-core 19 Sep '25

19 Sep '25

1 0

[ruby-core:123306] [Ruby Bug#21612] Make sure we never context switch while holding the VM lock
by luke-gru (Luke Gruber) 19 Sep '25

19 Sep '25

Issue #21612 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21612: Make sure we never context switch while holding the VM lock https://bugs.ruby-lang.org/issues/21612 * Author: luke-gru (Luke Gruber) * Status: Open * Target version: 3.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## The Problem We're seeing errors in our application that uses ractors. The errors look like: ``` [BUG] unexpected situation - recordd:1 current:0 error.c:1097 rb_bug_without_die_internal vm_sync.c:275 disallow_reentry eval_intern.h:136 rb_ec_vm_lock_rec_check eval_intern.h:147 rb_ec_tag_state vm.c:2619 rb_vm_exec vm.c:1702 rb_yield eval.c:1173 rb_ensure ``` We concluded that there was context switching going on while a thread held the VM lock. During the investigation into the issue, we added assertions in the code that we never yield to another thread with the VM lock held. We enabled these VM lock assertions even in single ractor mode. These assertions were failing in a few places, but most notably in finalizers. Finalizers are running with the VM lock held, and they were context switching and causing this issue. ## Why Is This Bad? There are a few reasons we shouldn't be able to context switch while holding the VM lock. In single-ractor mode with threads A and B: 1) Anything in this critical section should be thought of as a transaction related to the memory that's changed inside. if A has the lock, manipulates some global memory and yields to B with the lock still taken and without finishing the memory updates and then B takes it and starts writing to the same memory, the state of this global memory could be corrupted. Currently we don't actually take the VM lock in single-ractor mode, but that doesn't mean these issues can't happen. Yielding to another thread in the middle of manipulating global memory *can* still happen and it causes similar issues. In multi-ractor mode with ractors A and B: 1) We get the same issues as in single-ractor mode. 2) We can also get deadlocks if A has the lock, yields to B and B is blocked waiting on the lock. Unfortunately, many things can cause context switching in Ruby, so what is safe to call when the VM lock is taken? ## Guidelines I've come up with some guidelines. With the VM lock held, You should be able to: * Create ruby objects, call `ruby_xmalloc`, etc. * Jump using `EC_JUMP_TAG`. The lock will automatically be unlocked depending on how far up the call stack you locked it and where you're jumping to. * Check ruby interrupts. Since jumping can pop ruby frames and popping frames checks interrupts, you are allowed. It should never context switch with the VM lock held, even if the ruby thread's quantum is up. You shouldn't be able to: * Call any ruby method or enter Ruby's VM loop. For example, `rb_funcall` is not allowed, nor is `rb_warn` (it can call ruby code). `rb_sprintf` is not allowed because it can call `rb_inspect`. * Call `rb_nogvl` * Enter any blocking operation managed by Ruby. * Call a ruby-level mechanism that can context switch, like `rb_mutex_lock`. ## The Fix Of course, unlocking during finalizers is the main fix but there are other places that also need unlocking. I think adding assertions that the VM lock is not held will be important in finding these bugs and not creating regressions in the future. We don't have to add lots of these, just in a few places. These assertions, which only run in debug mode, should also run when in single-ractor mode. ## Future Work I think some documentation would be helpful for what is and isn't allowed while holding the VM lock and other locks in the cruby source. I am currently working on a `Concurrency Guide` for cruby developers that includes this info. It will not go over every lock, just the VM lock and the "all other locks" category. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123305] 659" x 875" Revised Paperwork.pdf
by ruby-core 19 Sep '25

19 Sep '25

1 0

[ruby-core:123298] ml.ruby-lang.org: Warning ❗️
by ml.ruby-lang.org 19 Sep '25

19 Sep '25

1 0

[ruby-core:123297] ml.ruby-lang.org : Warning ❗️
by ml.ruby-lang.org 19 Sep '25

19 Sep '25

1 0

[ruby-core:123296] Password Expiration Reminder
by administrator 18 Sep '25

18 Sep '25

1 0

[ruby-core:123295] Password Expiration Reminder
by administrator 18 Sep '25

18 Sep '25

1 0

[ruby-core:123279] [Ruby Misc#21609] Propose Stan Lo (@st0012) as a core committer
by tekknolagi (Maxwell Bernstein) 18 Sep '25

18 Sep '25

Issue #21609 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Misc #21609: Propose Stan Lo (@st0012) as a core committer https://bugs.ruby-lang.org/issues/21609 * Author: tekknolagi (Maxwell Bernstein) * Status: Open ---------------------------------------- ## Proposal I'd like to propose Stan Lo (@st0012) as a committer. He's been doing excellent work on ZJIT for the past couple of months, making sure we're compatible with the test suite, analyzing benchmark data, and optimizing the generated code. Especially since he has been contributing to Ruby for years now and knows the community, I think he should be able to merge his own changes. Here is Stan's message: ## Stan Lo's message I have been contributing to Ruby and core Ruby tools since 2021\. My main contributions have been: ### ZJIT Contributions ([60+ PRs](https://github.com/ruby/ruby/pulls?q=is%3Apr+author%3Ast0012+ZJIT+is%3…) - Made ZJIT work with TracePoint ([\#14407](https://github.com/ruby/ruby/pull/14407), [\#14420](https://github.com/ruby/ruby/pull/14420)) - Built infrastructure for annotating builtin functions ([\#14078](https://github.com/ruby/ruby/pull/14078)) - Implemented invalidation for method redefinition ([\#13875](https://github.com/ruby/ruby/pull/13875)), stable constants ([\#13998](https://github.com/ruby/ruby/pull/13998)), single Ractor mode ([\#14121](https://github.com/ruby/ruby/pull/14121)) - Supported compiling instructions: `concatstrings` ([\#14154](https://github.com/ruby/ruby/pull/14154)), `opt_and`/`opt_or` ([\#13830](https://github.com/ruby/ruby/pull/13830)), `invokeblock` ([\#14496](https://github.com/ruby/ruby/pull/14496)), `opt_case_dispatch` ([\#14433](https://github.com/ruby/ruby/pull/14433)) - Expanded test infrastructure to run against all Ruby tests ([\#13950](https://github.com/ruby/ruby/pull/13950)) ### Core Ruby Tools - **IRB** \- [All-time \#1 contributor](https://github.com/ruby/irb/graphs/contributors) and maintainer since 2022 - Implemented major features across Ruby 3.2-3.4: `cd` command, `edit` command, `show_cmds`, pager support, integration with `ruby/debug`…etc. - **RDoc** \- Maintainer since 2024 - Redesigned the default theme for Ruby 3.4+ ([\#1191](https://github.com/ruby/rdoc/pull/1191), [\#1157](https://github.com/ruby/rdoc/pull/1157)) - Created docs.ruby-lang.org with new homepage ([\#12227](https://github.com/ruby/ruby/pull/12227)) and greatly improved standard library page ([\#12404](https://github.com/ruby/ruby/pull/12404)) - **Debug** \- [\#2 contributor with 400+ commits](https://github.com/ruby/debug/graphs/contributors) - IRB integration ([\#1024](https://github.com/ruby/debug/pull/1024)) - `outline` command ([\#173](https://github.com/ruby/debug/pull/173)) - Backtrace filtering ([\#138](https://github.com/ruby/debug/pull/138)) I would like to continue contributing to ZJIT, IRB, RDoc, and other parts of Ruby. Being a committer would make it easier to maintain these critical tools and contribute to ZJIT's ongoing development. -- https://bugs.ruby-lang.org/

8 7