May 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120833] [Ruby master Bug#21099] TestGc#test_gc_stress_at_startup assertion failure
by sanjioh (Fabio Sangiovanni) 14 Jul '25

14 Jul '25

Issue #21099 has been reported by sanjioh (Fabio Sangiovanni). ---------------------------------------- Bug #21099: TestGc#test_gc_stress_at_startup assertion failure https://bugs.ruby-lang.org/issues/21099 * Author: sanjioh (Fabio Sangiovanni) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) +PRISM [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi all, I'm running macOS 15.2, and on my machine the test `TestGc#test_gc_stress_at_startup` results in an assertion failure. These are my current configure flags: ``` ../configure \ --prefix="$SOURCEDIR/ruby_3.4.1" \ --enable-debug-env \ --enable-devel \ cppflags="-DRUBY_DEBUG" \ optflags="-O0 -fno-omit-frame-pointer" ``` make command line for running tests (invoked from the build directory): ``` make test-all TESTS="../test/ruby/test_gc.rb --name=TestGc#test_gc_stress_at_startup" ``` output: ``` Run options: --seed=7555 "--ruby=./miniruby -I../lib -I. -I.ext/common ../tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=../test/.excludes --name=!/memory_leak/ --name=TestGc#test_gc_stress_at_startup # Running tests: [1/1] TestGc#test_gc_stress_at_startup = 3.18 s 1) Failure: TestGc#test_gc_stress_at_startup [/Users/fabio/ruby_xcode/ruby/test/ruby/test_gc.rb:776]: [Bug #15784] pid 16632 killed by SIGABRT (signal 6) | ../gc/default/default.c:1714: Assertion Failed: heap_add_poolpage:page->freelist != NULL | ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) [x86_64-darwin24] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | -- Control frame information ----------------------------------------------- | c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] | | | -- Threading information --------------------------------------------------- | Total ractor count: 0 | Ruby thread count for this ractor: 0 | | -- C level backtrace information ------------------------------------------- | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace+0x1d) [0x10515014d] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:823 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace) (null):0 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_vm_bugreport+0x2c1) [0x105150431] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:1155 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x156) [0x104e41056] /Users/fabio/ruby_xcode/ruby/build/../error.c:1215 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x0) [0x104e40f00] /Users/fabio/ruby_xcode/ruby/build/../error.c:1191 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure) (null):0 | /Users/fabio/ruby_xcode/ruby/build/ruby(heap_add_poolpage+0xa9) [0x104e84ea9] ../gc/default/default.c:1714 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_step+0x204) [0x104e80224] ../gc/default/default.c:3941 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_rest+0x53) [0x104e7fff3] ../gc/default/default.c:3979 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep+0x98) [0x104e7c418] ../gc/default/default.c:4151 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_start+0x5f9) [0x104e86159] ../gc/default/default.c:6472 | /Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect+0x2c) [0x104e87bbc] ../gc/default/default.c:6351 | /Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect_with_gvl+0xb4) [0x104e8dbc4] ../gc/default/default.c:6753 | /Users/fabio/ruby_xcode/ruby/build/ruby(objspace_malloc_gc_stress+0x8f) [0x104e8daff] ../gc/default/default.c:7996 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_gc_impl_malloc+0x49) [0x104e8d8f9] ../gc/default/default.c:8207 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2_body+0x32) [0x104e76a82] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4699 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2+0x1d) [0x104e76a3d] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4693 | /Users/fabio/ruby_xcode/ruby/build/ruby(pin_array_list_new+0x6f) [0x10511ab3f] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4389 | /Users/fabio/ruby_xcode/ruby/build/ruby(Init_vm_objects+0x1b) [0x10511aa6b] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4446 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_setup+0x46) [0x104e4f0e6] /Users/fabio/ruby_xcode/ruby/build/../eval.c:82 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_init+0xd) [0x104e4f3fd] /Users/fabio/ruby_xcode/ruby/build/../eval.c:98 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_main+0x2b) [0x104d2e6bb] /Users/fabio/ruby_xcode/ruby/build/../main.c:39 | /Users/fabio/ruby_xcode/ruby/build/ruby(main+0x62) [0x104d2e662] /Users/fabio/ruby_xcode/ruby/build/../main.c:65 | | -- Other runtime information ----------------------------------------------- | | * Process memory map: | | 104d2d000-105308000 r-x /Users/fabio/ruby_xcode/ruby/build/ruby | 105308000-105315000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby | 105315000-105317000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby | 105317000-10532c000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby | 10532c000-105500000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby | 105500000-105502000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105502000-105507000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105507000-105508000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105508000-10550c000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 10550c000-10550d000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 10550d000-105516000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105516000-105517000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105517000-105518000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105518000-105521000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105521000-105522000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105522000-105523000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105523000-105524000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105524000-10552b000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105530000-105540000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105573000-1055d3000 r-x /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055d3000-1055d7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055d7000-1055db000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055db000-1055e7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055e7000-105c3e000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby | 105c3e000-106295000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby | 600000000000-600020000000 rw- | 7f9643f00000-7f9644000000 rw- | 7f9644000000-7f9644800000 rw- | 7f9644800000-7f9644900000 rw- | 7f9644900000-7f9644901000 rw- | 7f9644a00000-7f9644b00000 rw- | 7ff7b71d3000-7ff7ba9d3000 --- | 7ff7ba9d3000-7ff7bb1d3000 rw- | 7ff800000000-7ff840000000 r-- | 7ff840000000-7ff844b02000 r-- | 7ff844b02000-7ff844b4a000 r-- | 7ff844b4a000-7ff844c00000 rw- | 7ff844c00000-7ff844e00000 rw- | 7ff844e00000-7ff845000000 rw- | 7ff845000000-7ff845200000 rw- | 7ff845200000-7ff845400000 rw- | 7ff845400000-7ff845600000 rw- | 7ff845600000-7ff880000000 r-- | 7ff880000000-7ffd40000000 r-- | 7ffd40000000-7ffd44400000 r-- | 7ffd44400000-7ffd44600000 rw- | 7ffd44600000-7ffd44800000 rw- | 7ffd44800000-7ffd80000000 r-- | 7ffd80000000-7ffffe000000 r-- | 7fffffe00000-7fffffe01000 r-- | 7ffffffad000-7ffffffae000 r-x | [IMPORTANT] | Don't forget to include the Crash Report log file under | DiagnosticReports directory in bug reports. | . 1. [2/3] Assertion for "stderr" | <[]> expected but was | <["../gc/default/default.c:1714: Assertion Failed: heap_add_poolpage:page->freelist != NULL", | "ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) [x86_64-darwin24]", | "", | "-- Crash Report log information --------------------------------------------", | " See Crash Report log file in one of the following locations:", | " * ~/Library/Logs/DiagnosticReports", | " * /Library/Logs/DiagnosticReports", | " for more details.", | "Don't forget to include the above Crash Report log file in bug reports.", | "", | "-- Control frame information -----------------------------------------------", | "c:0001 p:---- s:0003 e:000002 DUMMY [FINISH]", | "", | "", | "-- Threading information ---------------------------------------------------", | "Total ractor count: 0", | "Ruby thread count for this ractor: 0", | "", | "-- C level backtrace information -------------------------------------------", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace+0x1d) [0x10515014d] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:823", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace) (null):0", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_vm_bugreport+0x2c1) [0x105150431] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:1155", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x156) [0x104e41056] /Users/fabio/ruby_xcode/ruby/build/../error.c:1215", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x0) [0x104e40f00] /Users/fabio/ruby_xcode/ruby/build/../error.c:1191", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure) (null):0", | "/Users/fabio/ruby_xcode/ruby/build/ruby(heap_add_poolpage+0xa9) [0x104e84ea9] ../gc/default/default.c:1714", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_step+0x204) [0x104e80224] ../gc/default/default.c:3941", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_rest+0x53) [0x104e7fff3] ../gc/default/default.c:3979", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep+0x98) [0x104e7c418] ../gc/default/default.c:4151", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_start+0x5f9) [0x104e86159] ../gc/default/default.c:6472", | "/Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect+0x2c) [0x104e87bbc] ../gc/default/default.c:6351", | "/Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect_with_gvl+0xb4) [0x104e8dbc4] ../gc/default/default.c:6753", | "/Users/fabio/ruby_xcode/ruby/build/ruby(objspace_malloc_gc_stress+0x8f) [0x104e8daff] ../gc/default/default.c:7996", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_gc_impl_malloc+0x49) [0x104e8d8f9] ../gc/default/default.c:8207", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2_body+0x32) [0x104e76a82] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4699", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2+0x1d) [0x104e76a3d] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4693", | "/Users/fabio/ruby_xcode/ruby/build/ruby(pin_array_list_new+0x6f) [0x10511ab3f] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4389", | "/Users/fabio/ruby_xcode/ruby/build/ruby(Init_vm_objects+0x1b) [0x10511aa6b] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4446", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_setup+0x46) [0x104e4f0e6] /Users/fabio/ruby_xcode/ruby/build/../eval.c:82", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_init+0xd) [0x104e4f3fd] /Users/fabio/ruby_xcode/ruby/build/../eval.c:98", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_main+0x2b) [0x104d2e6bb] /Users/fabio/ruby_xcode/ruby/build/../main.c:39", | "/Users/fabio/ruby_xcode/ruby/build/ruby(main+0x62) [0x104d2e662] /Users/fabio/ruby_xcode/ruby/build/../main.c:65", | "", | "-- Other runtime information -----------------------------------------------", | "", | "* Process memory map:", | "", | "104d2d000-105308000 r-x /Users/fabio/ruby_xcode/ruby/build/ruby", | "105308000-105315000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby", | "105315000-105317000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby", | "105317000-10532c000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby", | "10532c000-105500000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby", | "105500000-105502000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105502000-105507000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105507000-105508000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105508000-10550c000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "10550c000-10550d000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "10550d000-105516000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105516000-105517000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105517000-105518000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105518000-105521000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105521000-105522000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105522000-105523000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105523000-105524000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105524000-10552b000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105530000-105540000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105573000-1055d3000 r-x /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055d3000-1055d7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055d7000-1055db000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055db000-1055e7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055e7000-105c3e000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby", | "105c3e000-106295000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby", | "600000000000-600020000000 rw-", | "7f9643f00000-7f9644000000 rw-", | "7f9644000000-7f9644800000 rw-", | "7f9644800000-7f9644900000 rw-", | "7f9644900000-7f9644901000 rw-", | "7f9644a00000-7f9644b00000 rw-", | "7ff7b71d3000-7ff7ba9d3000 ---", | "7ff7ba9d3000-7ff7bb1d3000 rw-", | "7ff800000000-7ff840000000 r--", | "7ff840000000-7ff844b02000 r--", | "7ff844b02000-7ff844b4a000 r--", | "7ff844b4a000-7ff844c00000 rw-", | "7ff844c00000-7ff844e00000 rw-", | "7ff844e00000-7ff845000000 rw-", | "7ff845000000-7ff845200000 rw-", | "7ff845200000-7ff845400000 rw-", | "7ff845400000-7ff845600000 rw-", | "7ff845600000-7ff880000000 r--", | "7ff880000000-7ffd40000000 r--", | "7ffd40000000-7ffd44400000 r--", | "7ffd44400000-7ffd44600000 rw-", | "7ffd44600000-7ffd44800000 rw-", | "7ffd44800000-7ffd80000000 r--", | "7ffd80000000-7ffffe000000 r--", | "7fffffe00000-7fffffe01000 r--", | "7ffffffad000-7ffffffae000 r-x", | "[IMPORTANT]", | "Don't forget to include the Crash Report log file under", | "DiagnosticReports directory in bug reports.", | ""]>. 2. [3/3] Assertion for "success?" | Expected #<Process::Status: pid 16632 SIGABRT (signal 6)> to be success?. Finished tests in 3.208725s, 0.3117 tests/s, 1.8699 assertions/s. 1 tests, 6 assertions, 1 failures, 0 errors, 0 skips ruby -v: ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) +PRISM [x86_64-darwin24] make: *** [uncommon.mk:965: yes-test-all] Error 1 ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122336] [Ruby Bug#21383] Prism leaks memory with invalid yield
by peterzhu2118 (Peter Zhu) 14 Jul '25

14 Jul '25

Issue #21383 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21383: Prism leaks memory with invalid yield https://bugs.ruby-lang.org/issues/21383 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- Fix: https://github.com/ruby/ruby/pull/13464 The following script leaks memory: ```ruby 10.times do 20_000.times do eval("class C; yield; end") rescue SyntaxError end puts `ps -o rss= -p #{$$}` end ``` Before: ``` 16464 25536 29424 35904 39552 44576 46736 51600 56096 59824 ``` After: ``` 13488 16160 18240 20528 19760 21808 21680 22272 22064 22336 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122218] [Ruby Bug#21357] Crash in Hash#merge! with ruby-dev in rubocop-rspec test suite
by Earlopain (Earlopain _) 14 Jul '25

14 Jul '25

Issue #21357 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21357: Crash in Hash#merge! with ruby-dev in rubocop-rspec test suite https://bugs.ruby-lang.org/issues/21357 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-20T09:22:41Z master a82e7132df) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've encountered crahses on ruby-head in recent days, related to hash methods like `merge` and `merge!`. I can now reproduce it locally while running the rubocop-rspec test suite: * Clone https://github.com/rubocop/rubocop-rspec * Run `NO_COVERAGE=1 bundle exec rake spec` I attached the crash report. I want to reduce this down but have no idea how. The crash is very consistent for me though, it doesn't take very long for it to happen (only a few seconds usually). There were changes to these methods like https://bugs.ruby-lang.org/issues/21305, maybe related. ---Files-------------------------------- test.log (224 KB) -- https://bugs.ruby-lang.org/

4 6

[ruby-core:122054] [Ruby Bug#21333] heap-use-after-free caused by rehash during update
by cyruscyliu (Qiang Liu) 14 Jul '25

14 Jul '25

Issue #21333 has been reported by cyruscyliu (Qiang Liu). ---------------------------------------- Bug #21333: heap-use-after-free caused by rehash during update https://bugs.ruby-lang.org/issues/21333 * Author: cyruscyliu (Qiang Liu) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-13T08:35:34Z master a6435befa7) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi, we found a heap-use-after-free caused by rehash during update ``` $a = (1..1337).to_h { |k| [k, k] } $a.update($b) { |k, o, n| $a.rehash } ``` ``` $ git log | head -n4 commit a6435befa76c2ae0525147f934bd9cd1914ffb8a Author: Jean Boussier <jean.boussier(a)gmail.com> Date: Mon May 12 11:02:17 2025 +0200 $ ./ruby triaged/hash_update.rb `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. ================================================================= ==227694==ERROR: AddressSanitizer: heap-use-after-free on address 0x52f00000e410 at pc 0x64f4179fa0d5 bp 0x7ffec17cce10 sp 0x7ffec17cce08 WRITE of size 8 at 0x52f00000e410 thread T0 #0 0x64f4179fa0d4 in rb_st_update /media/test/ruby/build/../st.c:1508:23 #1 0x64f417814018 in rb_hash_stlike_update /media/test/ruby/build/../hash.c:1686:12 #2 0x64f417814018 in tbl_update /media/test/ruby/build/../hash.c:1727:15 #3 0x64f417823d09 in rb_hash_update_block_i /media/test/ruby/build/../hash.c:4162:5 #4 0x64f417810576 in hash_ar_foreach_iter /media/test/ruby/build/../hash.c:1302:18 #5 0x64f417810576 in ar_foreach_check /media/test/ruby/build/../hash.c:944:22 #6 0x64f417810576 in hash_foreach_call /media/test/ruby/build/../hash.c:1435:15 #7 0x64f4177a45c6 in rb_ensure /media/test/ruby/build/../eval.c:1074:18 #8 0x64f417810329 in rb_hash_foreach /media/test/ruby/build/../hash.c:1463:9 #9 0x64f41781b88f in rb_hash_update /media/test/ruby/build/../hash.c:4219:13 #10 0x64f417b409db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #11 0x64f417b2904a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #12 0x64f417b28b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #13 0x64f417af0539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #14 0x64f417af0539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #15 0x64f417ae5cd7 in rb_vm_exec /media/test/ruby/build/../vm.c #16 0x64f4177a1bf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #17 0x64f4177a1bf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #18 0x64f41779d2b0 in rb_main /media/test/ruby/build/../main.c:42:12 #19 0x64f41779d2b0 in main /media/test/ruby/build/../main.c:62:12 #20 0x72d96ba2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #21 0x72d96ba2a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #22 0x64f4176c3d94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) 0x52f00000e410 is located 16 bytes inside of 49152-byte region [0x52f00000e400,0x52f00001a400) freed by thread T0 here: #0 0x64f41775e94a in free (/media/test/ruby/build/ruby+0x1e694a) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) #1 0x64f4177c944b in rb_gc_impl_free /media/test/ruby/build/../gc/default/default.c:8099:9 #2 0x64f4177c944b in ruby_sized_xfree /media/test/ruby/build/../gc.c:5225:13 #3 0x64f4177c944b in ruby_xfree /media/test/ruby/build/../gc.c:5236:5 #4 0x64f417811e09 in hash_st_free /media/test/ruby/build/../hash.c:1218:5 #5 0x64f417811e09 in rb_hash_rehash /media/test/ruby/build/../hash.c:2026:9 #6 0x64f417b409db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #7 0x64f417b2904a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #8 0x64f417b28b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #9 0x64f417aed6f3 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #10 0x64f417aed6f3 in vm_exec_core /media/test/ruby/build/../insns.def:899:11 #11 0x64f417ae5cd7 in rb_vm_exec /media/test/ruby/build/../vm.c #12 0x64f417b5bdcc in invoke_iseq_block_from_c /media/test/ruby/build/../vm.c:1653:12 #13 0x64f417b5bdcc in invoke_block_from_c_bh /media/test/ruby/build/../vm.c:1667:20 #14 0x64f417b0e2a7 in vm_yield_with_cref /media/test/ruby/build/../vm.c:1704:12 #15 0x64f417b0e2a7 in vm_yield /media/test/ruby/build/../vm.c:1712:12 #16 0x64f417b0e2a7 in rb_yield_0 /media/test/ruby/build/../vm_eval.c:1361:12 #17 0x64f417b0e2a7 in rb_yield_values /media/test/ruby/build/../vm_eval.c:1400:16 #18 0x64f417823db5 in rb_hash_update_block_callback /media/test/ruby/build/../hash.c:4148:31 #19 0x64f417823d48 in rb_hash_update_block_callback_insert /media/test/ruby/build/../hash.c:4157:1 #20 0x64f4178225c7 in tbl_update_modify /media/test/ruby/build/../hash.c:1696:15 #21 0x64f4179f9bea in rb_st_update /media/test/ruby/build/../st.c:1498:14 #22 0x64f417814018 in rb_hash_stlike_update /media/test/ruby/build/../hash.c:1686:12 #23 0x64f417814018 in tbl_update /media/test/ruby/build/../hash.c:1727:15 #24 0x64f417823d09 in rb_hash_update_block_i /media/test/ruby/build/../hash.c:4162:5 #25 0x64f417810576 in hash_ar_foreach_iter /media/test/ruby/build/../hash.c:1302:18 #26 0x64f417810576 in ar_foreach_check /media/test/ruby/build/../hash.c:944:22 #27 0x64f417810576 in hash_foreach_call /media/test/ruby/build/../hash.c:1435:15 #28 0x64f4177a45c6 in rb_ensure /media/test/ruby/build/../eval.c:1074:18 #29 0x64f417810329 in rb_hash_foreach /media/test/ruby/build/../hash.c:1463:9 #30 0x64f41781b88f in rb_hash_update /media/test/ruby/build/../hash.c:4219:13 #31 0x64f417b409db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #32 0x64f417b2904a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #33 0x64f417b28b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #34 0x64f417af0539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #35 0x64f417af0539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #36 0x64f417ae5cd7 in rb_vm_exec /media/test/ruby/build/../vm.c #37 0x64f4177a1bf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #38 0x64f4177a1bf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #39 0x64f41779d2b0 in rb_main /media/test/ruby/build/../main.c:42:12 #40 0x64f41779d2b0 in main /media/test/ruby/build/../main.c:62:12 #41 0x72d96ba2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #42 0x72d96ba2a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #43 0x64f4176c3d94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) previously allocated by thread T0 here: #0 0x64f41775ebe3 in malloc (/media/test/ruby/build/ruby+0x1e6be3) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) #1 0x64f417805df5 in rb_gc_impl_malloc /media/test/ruby/build/../gc/default/default.c:8114:5 #2 0x64f4177d49f2 in ruby_xmalloc_body /media/test/ruby/build/../gc.c:5116:12 #3 0x64f4177d49f2 in ruby_xmalloc /media/test/ruby/build/../gc.c:5106:34 #4 0x64f4179f44a1 in rb_st_init_existing_table_with_size /media/test/ruby/build/../st.c:559:39 #5 0x64f4179f65b0 in rb_st_init_table_with_size /media/test/ruby/build/../st.c:585:5 #6 0x64f4179f65b0 in rebuild_table /media/test/ruby/build/../st.c:753:19 #7 0x64f4179f65b0 in rebuild_table_if_necessary /media/test/ruby/build/../st.c:1125:9 #8 0x64f4179f6f6b in st_add_direct_with_hash /media/test/ruby/build/../st.c:1187:5 #9 0x64f4179f9cf3 in rb_st_update /media/test/ruby/build/../st.c:1502:13 #10 0x64f417814018 in rb_hash_stlike_update /media/test/ruby/build/../hash.c:1686:12 #11 0x64f417814018 in tbl_update /media/test/ruby/build/../hash.c:1727:15 #12 0x64f417813e82 in rb_hash_aset /media/test/ruby/build/../hash.c #13 0x64f417814510 in rb_hash_set_pair /media/test/ruby/build/../hash.c:3715:5 #14 0x64f417ae1bf3 in vm_yield_with_cfunc /media/test/ruby/build/../vm_insnhelper.c:5161:11 #15 0x64f417b5b7f9 in invoke_block_from_c_bh /media/test/ruby/build/../vm.c:1672:16 #16 0x64f417b0dcca in vm_yield_with_cref /media/test/ruby/build/../vm.c:1704:12 #17 0x64f417b0dcca in vm_yield /media/test/ruby/build/../vm.c:1712:12 #18 0x64f417b0dcca in rb_yield_0 /media/test/ruby/build/../vm_eval.c:1361:12 #19 0x64f417b0dcca in rb_yield /media/test/ruby/build/../vm_eval.c #20 0x64f4179371c7 in range_each_fixnum_loop /media/test/ruby/build/../range.c:1059:9 #21 0x64f4179371c7 in range_each /media/test/ruby/build/../range.c:1096:16 #22 0x64f417b53fd5 in vm_call0_cfunc_with_frame /media/test/ruby/build/../vm_eval.c:164:15 #23 0x64f417b53fd5 in vm_call0_cfunc /media/test/ruby/build/../vm_eval.c:178:12 #24 0x64f417b53fd5 in vm_call0_body /media/test/ruby/build/../vm_eval.c:229:15 #25 0x64f417b57a0a in vm_call0_cc /media/test/ruby/build/../vm_eval.c:101:12 #26 0x64f417b57a0a in rb_call0 /media/test/ruby/build/../vm_eval.c:571:12 #27 0x64f417b0f5f5 in rb_call /media/test/ruby/build/../vm_eval.c:890:12 #28 0x64f417b0f5f5 in iterate_method /media/test/ruby/build/../vm_eval.c:1545:12 #29 0x64f417b0fbf5 in rb_iterate0 /media/test/ruby/build/../vm_eval.c:1487:18 #30 0x64f417b0f287 in rb_iterate_internal /media/test/ruby/build/../vm_eval.c:1519:12 #31 0x64f417b0f287 in rb_block_call_kw /media/test/ruby/build/../vm_eval.c:1568:12 #32 0x64f417b0f287 in rb_block_call /media/test/ruby/build/../vm_eval.c:1554:12 #33 0x64f417dad5e0 in enum_hashify_into /media/test/ruby/build/../enum.c:743:5 #34 0x64f417dad5e0 in enum_hashify /media/test/ruby/build/../enum.c:750:12 #35 0x64f417dad5e0 in enum_to_h /media/test/ruby/build/../enum.c:791:12 #36 0x64f417b409db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #37 0x64f417b2904a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #38 0x64f417b28b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #39 0x64f417af0539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #40 0x64f417af0539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #41 0x64f417ae5cd7 in rb_vm_exec /media/test/ruby/build/../vm.c #42 0x64f4177a1bf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #43 0x64f4177a1bf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #44 0x64f41779d2b0 in rb_main /media/test/ruby/build/../main.c:42:12 #45 0x64f41779d2b0 in main /media/test/ruby/build/../main.c:62:12 #46 0x72d96ba2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #47 0x72d96ba2a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #48 0x64f4176c3d94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) SUMMARY: AddressSanitizer: heap-use-after-free /media/test/ruby/build/../st.c:1508:23 in rb_st_update Shadow bytes around the buggy address: 0x52f00000e180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52f00000e200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52f00000e280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52f00000e300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52f00000e380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x52f00000e400: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd 0x52f00000e480: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x52f00000e500: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x52f00000e580: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x52f00000e600: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x52f00000e680: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==227694==ABORTING triaged/hash_update.rb:3: [BUG] ASAN error ruby 3.5.0dev (2025-05-13T08:35:34Z master a6435befa7) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :update c:0002 p:0029 s:0006 e:000005 EVAL triaged/hash_update.rb:3 [FINISH] c:0001 p:0000 s:0003 E:000be0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- triaged/hash_update.rb:3:in '<main>' triaged/hash_update.rb:3:in 'update' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ./ruby(___interceptor_backtrace) [0x64f4177086aa] /media/test/ruby/build/ruby(rb_print_backtrace+0x14) [0x64f417e7bc97] /media/test/ruby/build/../vm_dump.c:843 /media/test/ruby/build/ruby(rb_vm_bugreport) /media/test/ruby/build/../vm_dump.c:1175 /media/test/ruby/build/ruby(rb_bug_without_die_internal+0x23c) [0x64f417dd016c] /media/test/ruby/build/../error.c:1097 /media/test/ruby/build/ruby(rb_bug_without_die+0x127) [0x64f417dcfe87] /media/test/ruby/build/../error.c:1106 ./ruby(0x64f4177832aa) [0x64f4177832aa] ./ruby(0x64f417763a2f) [0x64f417763a2f] ./ruby(0x64f417766ab5) [0x64f417766ab5] ./ruby(__asan_report_store8) [0x64f417767bdf] /media/test/ruby/build/ruby(rb_st_update+0xcd5) [0x64f4179fa0d5] /media/test/ruby/build/../st.c:1508 /media/test/ruby/build/ruby(tbl_update+0x139) [0x64f417814019] /media/test/ruby/build/../hash.c:1686 /media/test/ruby/build/ruby(rb_hash_update_block_i+0x3a) [0x64f417823d0a] /media/test/ruby/build/../hash.c:4162 /media/test/ruby/build/ruby(hash_ar_foreach_iter+0x10) [0x64f417810577] /media/test/ruby/build/../hash.c:1302 /media/test/ruby/build/ruby(ar_foreach_check) /media/test/ruby/build/../hash.c:944 /media/test/ruby/build/ruby(hash_foreach_call) /media/test/ruby/build/../hash.c:1435 /media/test/ruby/build/ruby(rb_ensure+0x257) [0x64f4177a45c7] /media/test/ruby/build/../eval.c:1074 /media/test/ruby/build/ruby(rb_hash_foreach+0x23a) [0x64f41781032a] /media/test/ruby/build/../hash.c:1463 /media/test/ruby/build/ruby(rb_hash_update+0xe0) [0x64f41781b890] /media/test/ruby/build/../hash.c:4219 /media/test/ruby/build/ruby(vm_cfp_consistent_p+0x0) [0x64f417b409dc] ../vm_insnhelper.c:3798 /media/test/ruby/build/ruby(vm_call_cfunc_with_frame_) ../vm_insnhelper.c:3800 /media/test/ruby/build/ruby(vm_call_method_each_type+0x27b) [0x64f417b2904b] ../vm_insnhelper.c:4776 ./ruby(vm_call_method+0x2d4) [0x64f417b28b14] /media/test/ruby/build/ruby(vm_sendish+0x11f) [0x64f417af053a] ../vm_insnhelper.c:5995 /media/test/ruby/build/ruby(vm_exec_core) ../insns.def:851 ./ruby(vm_exec_loop+0x0) [0x64f417ae5cd8] /media/test/ruby/build/ruby(rb_vm_exec) /media/test/ruby/build/../vm.c:2626 /media/test/ruby/build/ruby(rb_ec_exec_node+0x53) [0x64f4177a1bf1] /media/test/ruby/build/../eval.c:281 /media/test/ruby/build/ruby(ruby_run_node) /media/test/ruby/build/../eval.c:319 /media/test/ruby/build/ruby(rb_main+0x29) [0x64f41779d2b1] /media/test/ruby/build/../main.c:42 /media/test/ruby/build/ruby(main) /media/test/ruby/build/../main.c:62 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x72d96ba2a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x72d96ba2a28b] ../csu/libc-start.c:360 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 ./ruby(_start) [0x64f4176c3d95] -- Other runtime information ----------------------------------------------- * Loaded script: triaged/hash_update.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 set.rb ``` -- https://bugs.ruby-lang.org/

6 8

[ruby-core:121437] [Ruby Bug#21197] Prism does not accept newline after defined? keyword
by kddnewton (Kevin Newton) 14 Jul '25

14 Jul '25

Issue #21197 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21197: Prism does not accept newline after defined? keyword https://bugs.ruby-lang.org/issues/21197 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` defined? (1) ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122154] [Ruby Feature#21346] Introduce `String#ensure_suffix`
by matheusrich (Matheus Richard) 14 Jul '25

14 Jul '25

Issue #21346 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21346: Introduce `String#ensure_suffix` https://bugs.ruby-lang.org/issues/21346 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- ## Problem Ensuring a string has a specific suffix or prefix is a common operation in many applications. Bundler itself uses it: https://github.com/rubygems/rubygems/blob/d409ec8b5fc647fabe30e37e17cd1ea85… Here are [GitHub search](https://github.com/search) queries that might find this pattern in other places: 1. for Ruby: `/end(?:s)?_with\?$['"].*['"]$ \?/ lang:ruby -is:fork` 1. for Crystal (a language very similar to Ruby): `/ends_with\?$['"].*['"]$ \?/ lang:crystal -is:fork` ## Suggested solution I believe Ruby would benefit from having a first-class method for this purpose. I suggest the `String#ensure_suffix` and `String#ensure_prefix` methods. I think these names are intuitive enough (here are 2 examples of people using `ensure` for this purpose ([1](https://github.com/boltops-tools/ufo/blob/796104fdb89163d09a58fad42add69…, [2](https://github.com/mumuki/mumuki-domain/blob/6194089d82b1a0c8805ecba98e0…)) I've gone ahead and implemented `String#ensure_suffix` in a [pull request](https://github.com/ruby/ruby/pull/13366) but the suggested behavior is this: ```rb "Hell".ensure_suffix("o!") # => "Hello!" "Hello!".ensure_suffix("o!") # => "Hello!" s = "Hello!" s.ensure_suffix("!").equal?(s) # => true # returns same object if already suffixed ``` -- https://bugs.ruby-lang.org/

8 20

[ruby-core:120618] [Ruby master Bug#21029] Prism behavior for `defined? (;x)` differs
by qnighy (Masaki Hara) 14 Jul '25

14 Jul '25

Issue #21029 has been reported by qnighy (Masaki Hara). ---------------------------------------- Bug #21029: Prism behavior for `defined? (;x)` differs https://bugs.ruby-lang.org/issues/21029 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-11T03:21:57Z master 1b3037081e) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism has a different behavior for `(;expr)` when used in `defined?` predicate: ```console % ./miniruby --parser=prism -e "p defined? (;x)" nil % ./miniruby --parser=parse.y -e "p defined? (;x)" "expression" ``` Although not a significant difference, aligning either of them with the other would be better. -- https://bugs.ruby-lang.org/

5 11

[ruby-core:111027] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors
by fxn (Xavier Noria) 14 Jul '25

14 Jul '25

Issue #19154 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #19154: Specify require and autoload guarantees in ractors https://bugs.ruby-lang.org/issues/19154 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given a file `c.rb`: ```ruby class C end ``` the following script: ```ruby r1 = Ractor.new do require './c.rb' end r2 = Ractor.new do require './c.rb' end r1.take r2.take ``` raises: ``` % ruby -v foo.rb ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] foo.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x000000010fee2928 run> terminated with exception (report_on_exception is true): #<Thread:0x00000001102acfe0 run> terminated with exception (report_on_exception is true): <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:6:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require'<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': : can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' from foo.rb:6:in `block in <main>' <internal:ractor>:698:in `take': thrown by remote Ractor. (Ractor::RemoteError) from foo.rb:9:in `<main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' ``` Would it be possible to have documentation about their interaction? This is important also to understand autoloading within ractors, since constant references may trigger `require` calls. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:121621] [Ruby Feature#21262] Proposal: `Ractor::Port`
by ko1 (Koichi Sasada) 08 Jul '25

08 Jul '25

Issue #21262 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21262: Proposal: `Ractor::Port` https://bugs.ruby-lang.org/issues/21262 * Author: ko1 (Koichi Sasada) * Status: Assigned * Assignee: ko1 (Koichi Sasada) * Target version: 3.5 ---------------------------------------- # Proposal: `Ractor::Port` In concurrent Ruby applications using Ractors, safely and efficiently communicating results between Ractors is a common challenge. We propose `Ractor::Port` as a lightweight, safe, and ergonomic abstraction to simplify communication patterns, especially in request-response models. ```ruby # usage example port = Ractor::Port.new Ractor.new port do |port| port << 42 port << 43 end # Success: wait for sending port.receive #=> 42 Ractor.new port do |port| port.receive # Error: only the creator Ractor can receive from this port. end port.receive #=> 43 ``` This is a similar concept to ["Channel"](https://bugs.ruby-lang.org/issues/21121), but it is tightly coupled with the creator Ractor and no other Ractors can receive anything from that port. In that sense, it is conceptually closer to a socket file descriptor (e.g., a destination and port number pair in TCP/IP). We can implement `Port` with `Ractor.receive_if` like this: ```ruby class Ractor::Port def initialize @r = Ractor.current @tag = genid() end def send obj @r << [@tag, obj] end def receive raise unless @r == Ractor.current Ractor.receive_if do |(tag, result) if tag == @tag return result end end end end ``` With `Ractor::Port`, we can deprecate `Ractor.receive_if`, `Ractor.yield`, and `Ractor#take`. Ports act as clear, self-contained endpoints for message passing, which makes these older primitives redundant. Furthermore, Port-based communication is significantly easier to implement and reason about—especially when considering synchronization challenges around `Ractor.select` and rendezvous semantics. ## Background: Limitations of current communication patterns Let's discuss how to make server-like service ractors. ### No response server We can make server-like Ractors like this: ```ruby # EX1 def fib(n) = n > 1 : fib(n-2) + fib(n-1) : 1 # A ractor calculate fib(n) fib_srv = Ractor.new do while true param = Ractor.receive result = fib(param) end end fib_srv << 10 ``` In this case, the main Ractor requests `fib_srv` to calculate `fib(10)`. However, currently, there is no way to retrieve the result. ### Return value to the sender ractor There are several possible approaches. First, we can send the sender Ractor along with the parameter, and ask the server to send the result back to the sender. ```ruby # EX2 fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fib_srv << [10, Ractor.current] do_some_work() Ractor.receive #=> fib(10) ``` This approach works well in simple cases. However, with EX2, handling multiple concurrent responses becomes difficult. The results are pushed into the same mailbox, and since `Ractor.receive` retrieves messages without discriminating the source, it's unclear which server returned which result. ```ruby # EX3 def fact(n) = n > 1 : fact(n-1) * n fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << result end end fib_srv << [10, Ractor.current] fib_srv << [20, Ractor.current] fact_srv << [10, Ractor.current] fact_srv << [20, Ractor.current] do_some_work() Ractor.receive #=> fib(10) or fact(10), which? # If the servers uses Ractors more (calculate them in parallel), # fib(20) and fact(20) can be returned. ``` Because `Ractor.receive` retrieves all messages indiscriminately, developers must add their own tagging logic to distinguish results. While tagging (as shown in EX4) helps, it introduces additional complexity and brittleness. ### Responses with request ID The following code returns a result with request id (a pair of the name of server and a parameter). ```ruby # EX4 fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << [[:fib, param], result] end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << [[:fact, param], result] end end do_some_work() fib_srv << [10, Ractor.current] fib_srv << [20, Ractor.current] fact_srv << [10, Ractor.current] fact_srv << [20, Ractor.current] Ractor.receive_if do |id, result| case id in [:fib, n] p "fib(#{n}) = #{result}" in [:fact, n] p "fact(#{n}) = #{result}" end end # or if you want to use specific results, like: p fib20: Ractor.receive_if{|id, result| id => [:fib, 20]; result} p fact10: Ractor.receive_if{|id, result| id => [:fact, 10]; result} p fact20: Ractor.receive_if{|id, result| id => [:fact, 20]; result} p fib10: Ractor.receive_if{|id, result| id => [:fib, 10]; result} ``` This approach closely resembles pattern matching in Erlang or Elixir, where responses are tagged and matched structurally. However, this solution still has an issue: if `do_some_work()` uses `Ractor.receive`, it may accidentally consume any message. In other words, `Ractor.receive` can only be safely used when you're certain that no other code is using it. (Another trivial issue is, different servers can return same identity, like `[:fact, num]` returned by NewsPaper server. It is confusing). ### Using channels To solve this issue, we can make a channel with different Ractors. Channels can be implemented using Ractors, as illustrated below. ```ruby # EX5 # Servers are completely same to EX3 fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << result end end # Create a new channel using a Ractor def new_channel Ractor.new do while true Ractor.yield Ractor.receive end end end fib_srv << [10, fib10_ch = new_channel] fib_srv << [20, fib20_ch = new_channel] fact_srv << [10, fact10_ch = new_channel] fact_srv << [20, fact20_ch = new_channel] do_something() p fib20: fib20_ch.take # wait for fib(20) p fact10: fact10_ch.take # wait for fact(10) p fib10: fib10_ch.take # wait for fib(10) p fact20: fact10_ch.take # wait for fact(20) # or chs = [fib10_ch, fib20_ch, fact10_ch, fact20_ch] while !chs.empty? ch, result = Ractor.select(*chs) # wait for multiple channels p ch, result chs.delete ch end ``` Channel approach solves the issue of EX4. The above implementation introduce some overhead to create channel ractors, but we can introduce special implementation to reduce this Ractor creation overhead. However, in the Actor model, the communication pattern is to send a message to a specific actor. In contrast, channels are used to send messages through a shared conduit, without caring which receiver (if any) handles the message. Also, channels can have some overhead, as discussed below. ### Summary of background Currently, when implementing request-response patterns with Ractors, developers face challenges in tracking results, managing identifiers, and avoiding message conflicts. Existing primitives like `receive_if`, `take`, or channels implemented with Ractors are either error-prone or inefficient. ## Proposal Introduce `Ractor::Port` as an alternative to channels. It is a natural extension of the Actor model. In fact, it is thin wrapper of current send/receive model as illustrated at the top of this proposal. With the `Ractor::Port`, we can rewrite above examples with it. ```ruby # EX6 # Completely same as EX3's servers fib_srv = Ractor.new do while true param, sender = Ractor.receive result = fib(param) sender << result end end fact_srv = Ractor.new do while true param, sender = Ractor.receive result = fact(param) sender << result end end fib_srv << [10, fib10_port = Ractor::Port.new] fib_srv << [20, fib20_port = Ractor::Port.new] fact_srv << [10, fact10_port = Ractor::Port.new] fact_srv << [20, fact20_port = Ractor::Port.new] do_something p fib10_port.receive #=> fib(10) p fib20_port.receive #=> fib(20) p fact10_port.receive #=> fact(10) p fact20_port.receive #=> fact(20) # or ports = [fib10_port, fib20_port, fact10_port, fact20_port] while !ports.empty? port, result = Ractor.select(*ports) case port when fib10_port p fib10: result ... else raise "This should not happen (BUG)." end ports.delete(port) end ``` `Ractor::Port` resolves key pain points in message passing between Ractors: * It guarantees that incoming messages are only delivered to the intended Ractor, preventing tag collisions. * It enables message routing without relying on global receive blocks (`Ractor.receive`), which are prone to unintended consumption. * It replaces more complex primitives like `.receive_if`, `.yield`, and `#take` with a simpler, composable abstraction. * It maps cleanly to the Actor model semantics Ruby intends to support with Ractors. While the pattern looks similar to using channels, the semantics and guarantees are different in meaningful ways. The advantages of using Ports include: * Safer than channels in practice * When using a Port, if `#send` succeeds, it means the destination Ractor is still alive (i.e., it's running). * In contrast, with a channel, there's no guarantee that any Ractor is still available to receive from it. * Of course, even with a port, there's no guarantee that the destination Ractor will actually process the message — it might ignore it. * But at least you don't need to worry about the Ractor having already terminated unexpectedly. * In other words, using a port eliminates one major failure case, making the communication model more predictable. * This is one of the reasons why Ruby went with the "Actor" model (hence the name Ractor), instead of the "CSP" model. * Faster than channels in both creation and message transmission * When creating a channel, we need to prepare a container data structure. When creating a port, it is lightweight data (a pair of Ractor and newly created ID). * On the channel transmission, we need copying a data to channel and a copying to the receiving ractor. On the port, it only needs to copy from the src ractor to the dst ractor. This issue becomes more significant due to Ractor-local garbage collection and isolation of object spaces. * Easy to implement. We only need to implement `Port#receive` to synchronize with other ractors. * `#send/.receive` is easy to implement because we only need to lock the receiving ractor. * `.yield/#take` is not easy to implement because we need to lock taking and receiving ractors because it is rendezvous style synchronization. * `.select` is DIFFICULT to support current spec. Now CI doesn't stable yet. * A simpler spec reduces bugs, and maybe leads to faster implementation. Disadvantages: 1. It is not a well-known concept, especially for Go language users. 2. We need additional abstraction like producer(s)-consumer(s) concurrent applications. For (2), I want to introduce an example code. We can write a 1-producer, multiple-consumer pattern with a channel. ```ruby # channel version of 1 producer & consumers ch = new_channel RN = 10 # make 10 consumers consumers = RN.times.map do Ractor.new ch do while param = ch.receive task(param) end end end tasks.each do |task| ch << task end ``` With Port, we need to introduce a load balancing mechanism: ```ruby # Port version of 1 producer & consumers control_port = Ractor::Port.new consumers = RN.times.map do Ractor.new control_port control_port do |control_port| while true control_port << [:ready, Ractor.current] # register - ready param = Ractor.receive # it assumes task doesn't use Ractor.receive task(param) end end end tasks.each do |task| control_port.receive => [:ready, consumer] # send a task to a ready consumer consumer << task end ``` Of course we can make a library for that (like OTP on Erlang). ### Default port of Ractors Each Ractor has a default port and `Ractor#send` is equal to `Ractor.current.default_port#send`. Of course, `Ractor.receive` is equal to `Ractor.current.default_port.receive`. For the simple case, we can keep to use `Ractor#send` and `Ractor.receive` ### Deprecation of Ractor#take and Ractor.yield With the Port concept, we can focus solely on send and receive—that is, direct manipulation of a Ractor’s mailbox. Ports provide a clean and functional alternative to `Ractor#take` and `Ractor.yield`, making them unnecessary in most use cases. Moreover, Ports are significantly easier to implement, as they require only locking the receiving Ractor, while yield/take involve complex rendezvous-style synchronization. By removing these primitives, we can simplify the specification and reduce implementation complexity—especially around features like `Ractor.select`, which are notoriously hard to get right. ### `Ractor.select` with ports We should wait for multiple port simultaneously so `Ractor.select()` should accept ports. Now `Ractor.select()` can also receiving and yielding the value, but if we remove the `#take` functionality, `Ractor.select` only need to support ports. ### Wait for termination `Ractor#take` is designed from an idea of getting termination result (like `Thread#value`). For this purpose, we can introduce `Ractor#join` or `Ractor#value` like Threads or we can keep the name `Ractor#take` for this purpose. We can make `Ractor#join` as a following pseudo-code: ```ruby class Ractor def join # wait for the termination register_termination_port port = Port.new port.receive end # when this ractor terminates, send a message to the registered port def monitor port @monitor_port = port end private def atexit @monitor_port << termination_message end end # there are some questions. # * can we register multiple ports? # * should we support `#join` and `#value` like threads? # or should we support only `#join` to return the value? # * or keep this name as `#take`? Ractor.new do 42 end.join #=> 42 (or true?) ``` It is very similar to `monitor` in Erlang or Elixir. We can also make a supervisor in Erlang like that: ```ruby sv_port = Ractor::Port.new rs = N.times.map do Ractor.new do do_something() end.monitor sv_port end while termination_notice = sv_port.receive p termination_notice end # With Ractor#take, we can write similar code if there is no Ractor.yield rs = N.times.map do Ractor.new do do_something() end end while r, msg = Ractor.select(*rs) p [r, msg] end ``` ## Discussion ### `send` with tag (symbols) If we force users to send a tagged message every time, we can achieve the same effect as Port concept, because a Port can be thought of as a combination of a tag and a destination Ractor. ```ruby r = Ractor.new do loop do tag, msg = Ractor.receive # return 2 values case tag when :TAG p [tag, msg] else # ignore end end end r.send :TAG, 42 r.send :TAGE, 84 # this typo and the message is silently ignored ``` However it has two issues: * If we make a typo in tag name, the message will be silently ignored. * The tag name may conflict with unrelated codes (libraries) ### `Ractor.yield` and `Ractor#take` with channel ractor If we want to leave the `.yield` and `#take`, we can emulate them with channel ractor. ```ruby class Ractor def initialize @yield_ractor = Ractor.new do takers = [] while tag, msg = Ractor.receive case tag when :register @takers << msg when :unregister @takers.delete msg when :yield @takers.pop << msg end end end end def self.yield obj @yield_ractor << [:yield, obj] end def take @yield_ractor << [:register, port = Ractor::Port.new] port.receive ensure @yield_ractor << [:unregister, port] end end ``` ### Opening and closing the port This proposal doesn't contain opening and closing the port, but we can discuss about it. To introduce this attribute, we need to manage which ports (tags) are opening. ## Implementation Now the native implementation is not finished, but we can implement it using the `Ractor.receive_if` mechanism, so we estimate that only a few weeks of work are needed to complete it. ## Summary This proposal introduces the following features and deprecations. * `Ractor::Port` * `Port#send(msg)` – sends a message to the creator of the port. * `Port#receive` – receives a message from the port. * A port is a lightweight data structure (a pair of a Ractor and a tag). * `Ractor#join` or `Ractor#value` – to wait for Ractor termination (like `Thread#join`) * `Ractor#monitor` – to observe when another Ractor terminates * Deprecations: * `Ractor#take` * `Ractor.yield` * `Ractor.receive_if` Thank you for reading this long proposal. If you have any use cases that cannot be addressed with `Ractor::Port`, I'd love to hear them. P.S. Thanks to mame for reviewing this proposal and suggesting that I use ChatGPT to improve the writing. -- https://bugs.ruby-lang.org/

2 7

[ruby-core:122238] [Ruby Bug#21362] Namespace: Inline method caches poisoned with builtins
by jhawthorn (John Hawthorn) 08 Jul '25

08 Jul '25

Issue #21362 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21362: Namespace: Inline method caches poisoned with builtins https://bugs.ruby-lang.org/issues/21362 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby File.write("/tmp/ntest.rb", <<~'RUBY') class Integer def succ = self + 2 end module Test def self.run = 10.times.to_a end RUBY module Test def self.run = 10.times.to_a end ns = Namespace.new ns.require("/tmp/ntest.rb") p namespaced: ns::Test.run p main: Test.run ``` ``` RUBY_NAMESPACE=1 ruby test_namespace_succ.rb ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. {namespaced: [0, 2, 4, 6, 8]} {main: [0, 2, 4, 6, 8]} ``` What's happening here is that we have a number of "builtin" Ruby files which are loaded during the VM boot. The instruction sequences and method definitions from these files end up as part of the "root" namespace. However this iseq can still include inline caches, and in this example we see the cache poisoned by being run in a namespace with succ redefined. I was surprised by this, I expected it to call using the "root" namespace. It's definitely a strange edge-case to redefine `succ`, but the namespace semantics here are important because how this is defined impacts how useful builtins can be: - If builtins inherit their namespace from the caller, then they cannot use inline caches (or inline caches must always check for namespace validity) and also cannot be JIT compiled (unless the JIT also checks for namespace validity, and given the complexity of rb_current_namespace, it would be very undesirable). This is very bad as converting C code to builtin Ruby has been important for getting better performance. - If builtins make calls using the "root" namespace, inline caching and the JIT should work (actually there may be advantages to both since the namespace is mostly immutable). However this will limit what we are able to move from C to Ruby, as it wouldn't be possible to have the same semantics as C methods (where the caller's namespace is used). -- https://bugs.ruby-lang.org/

4 3