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

[ruby-core:122561] [Ruby Bug#21447] Fix handling of PM_CONSTANT_PATH_NODE node in keyword arguments with ARGS_SPLAT
by jeremyevans0 (Jeremy Evans) 14 Jul '25

14 Jul '25

Issue #21447 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21447: Fix handling of PM_CONSTANT_PATH_NODE node in keyword arguments with ARGS_SPLAT https://bugs.ruby-lang.org/issues/21447 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Assignee: jeremyevans0 (Jeremy Evans) * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- I added an optimization to reduce implicit allocations when using parse.y in commit:3de20efc308cccc38bf9dacfffca6c626d039a06. An implementation was added for prism in commit:14bb376b79ca9140bfd36dbbad06be045f31f92e. Unfortunately, when I added tests for the optimization, I only tested the optimizable case for `NODE_COLON2` (`Foo::Bar`). I neglected to add a test for the unoptimizable case (`foo()::Bar`). The prism implementation of the optimization incorrectly optimized the unoptimizable case (for `PM_CONSTANT_PATH_NODE`), but that's because the tests did not fail when it was incorrectly optimized. This can cause an evaluation order issue in the following code if `foo` modifies `array`: ```ruby method(*array, kw: foo(array)::Bar) ``` I've submitted a PR that adds tests for the unoptimizable case, and fixes the prism implementation of the optimization: https://github.com/ruby/ruby/pull/13664 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122554] [Ruby Bug#21443] Backport: Fix heap-use-after-free in free_fast_fallback_getaddrinfo_entry
by rochlefebvre (Roch Lefebvre) 14 Jul '25

14 Jul '25

Issue #21443 has been reported by rochlefebvre (Roch Lefebvre). ---------------------------------------- Bug #21443: Backport: Fix heap-use-after-free in free_fast_fallback_getaddrinfo_entry https://bugs.ruby-lang.org/issues/21443 * Author: rochlefebvre (Roch Lefebvre) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Please backport the following AddressSanitizer error into Ruby 3.4 https://github.com/ruby/ruby/pull/13231 I did not find a ticket related to the original fix. Thank you! -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122327] [Ruby Bug#21380] Use-After-Free in String#split with In-Block String Modification
by bytesmith (Orin Nova) 14 Jul '25

14 Jul '25

Issue #21380 has been reported by bytesmith (Orin Nova). ---------------------------------------- Bug #21380: Use-After-Free in String#split with In-Block String Modification https://bugs.ruby-lang.org/issues/21380 * Author: bytesmith (Orin Nova) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A use-after-free bug can be triggered in Ruby's String#split when the target string is modified within the block passed to split. Ruby version: ``` ./ruby -v ruby 3.5.0dev (2025-05-28T04:34:40Z master d064fd067b) +PRISM [x86_64-linux] ``` Program input: ``` str = "one two" def mutate(s) s.prepend("junk" * 1000) end counter = 0 loop do str.split { mutate(str) } counter += 1 break if counter > 10 end ``` ASAN output: ``` ================================================================= ==30097==ERROR: AddressSanitizer: heap-use-after-free on address 0x526000002fe4 at pc 0x562c9f1bad20 bp 0x7ffc937b5440 sp 0x7ffc937b5430 READ of size 1 at 0x526000002fe4 thread T0 #0 0x562c9f1bad1f in rb_str_split_m ../string.c:9765 #1 0x562c9f2eb9c5 in vm_call_cfunc_with_frame_ ../vm_insnhelper.c:3774 #2 0x562c9f3056f6 in vm_sendish ../vm_insnhelper.c:5971 #3 0x562c9f3543b7 in vm_exec_core ../insns.def:851 #4 0x562c9f32315e in rb_vm_exec ../vm.c:2625 #5 0x562c9f367157 in rb_iseq_eval_main ../vm.c:2905 #6 0x562c9ee6078a in rb_ec_exec_node ../eval.c:281 #7 0x562c9ee67e4d in ruby_run_node ../eval.c:319 #8 0x562c9ee575c1 in rb_main ../main.c:42 #9 0x562c9ee575c1 in main ../main.c:62 #10 0x7f7ecc8811c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 42c84c92e6f98126b3e2230ebfdead22c235b667) #11 0x7f7ecc88128a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 42c84c92e6f98126b3e2230ebfdead22c235b667) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122215] [Ruby Bug#21356] Error when accessing local variable named "default" with Binding#local_variable_get
by richardboehme 14 Jul '25

14 Jul '25

Issue #21356 has been reported by richardboehme (Richard Böhme). ---------------------------------------- Bug #21356: Error when accessing local variable named "default" with Binding#local_variable_get https://bugs.ruby-lang.org/issues/21356 * Author: richardboehme (Richard Böhme) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-21T06:12:18Z master f6cbf499bc) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Ruby master when using `Binding#local_variable_get` with the name `:default` it raises the following error: ``` 'Binding#local_variable_get': numbered parameter 'default' is not a local variable (NameError) ``` I saw that this error was introduced in #21049 but it seems like the check for whether the passed variable name is a numbered parameter does not work for the `:default` symbol. I think this might be an off-by-one error in the `rb_numparam_id_p` function in proc.c, where instead of adding 9 (the maximum number of numbered parameters) to tNUMPARAM_1 we currently add 10 which then includes the id of default as well? Compiling with this change (see attached diff) fixed the issue but I'm not sure if it might break other things. ---Files-------------------------------- patch.diff (384 Bytes) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:122274] [Ruby Bug#21370] `it` can cause ISeq serialization failure
by byroot (Jean Boussier) 14 Jul '25

14 Jul '25

Issue #21370 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21370: `it` can cause ISeq serialization failure https://bugs.ruby-lang.org/issues/21370 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- Originally reported at: https://github.com/rails/rails/issues/55108 ```ruby iseq = RubyVM::InstructionSequence.compile(<<~'RUBY') [1].each do rescue => e puts it end RUBY iseq.to_binary # CRASH ``` ``` miniruby(sigsegv) (null):0 miniruby(RB_FL_ANY_RAW+0x20) [0x1010ac504] internal/fl_type.h:507 miniruby(rbimpl_rstring_getmem+0x20) [0x101090674] internal/core/rstring.h:393 miniruby(rb_str_cmp+0x4c) [0x10109920c] string.c:4541 miniruby(outer_variable_cmp+0x3c) [0x100e43b64] compile.c:13381 miniruby(cmp_bsd_qsort+0x3c) [0x1010fe810] util.c:239 miniruby(ruby_qsort+0x5c) [0x1010fe7a8] util.c:248 miniruby(ibf_dump_outer_variables+0x150) [0x100e43708] compile.c:13402 miniruby(ibf_dump_iseq_each+0x19c) [0x100e423cc] compile.c:13527 miniruby(ibf_dump_iseq_list_i+0x38) [0x100e420fc] compile.c:13862 miniruby(apply_functor+0x40) [0x10107bad8] st.c:1644 ``` It is crashing while trying to sort outer variables, and `it` is anonymous. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:121721] [Ruby Bug#21283] Some tests of TestMkmfConvertible is failing with VS2022 17.14.0 preview 4.0
by hsbt (Hiroshi SHIBATA) 14 Jul '25

14 Jul '25

Issue #21283 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21283: Some tests of TestMkmfConvertible is failing with VS2022 17.14.0 preview 4.0 https://bugs.ruby-lang.org/issues/21283 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following tests are broken with VS2022 17.14.0 preview 4.0. ``` 1) Error: TestMkmfConvertible#test_typeof_typedef: Test::Unit::ProxyError: invalid byte sequence in UTF-8 V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:21:in 'block (2 levels) in TestMkmfConvertible#test_typeof_typedef' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:16:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:16:in 'block in TestMkmfConvertible#test_typeof_typedef' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:15:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:15:in 'TestMkmfConvertible#test_typeof_typedef' 2) Error: TestMkmfConvertible#test_typeof_builtin: Test::Unit::ProxyError: invalid byte sequence in UTF-8 V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:8:in 'block (2 levels) in TestMkmfConvertible#test_typeof_builtin' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:7:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:7:in 'block in TestMkmfConvertible#test_typeof_builtin' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:6:in 'Array#each' V:/github.com/ruby/ruby/test/mkmf/test_convertible.rb:6:in 'TestMkmfConvertible#test_typeof_builtin' ``` They are working fine with VS2019. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:122101] [Ruby Bug#21340] Bump autoconf version to properly handle C23 bool/stdbool defines
by christo (Chris Alberti) 14 Jul '25

14 Jul '25

Issue #21340 has been reported by christo (Chris Alberti). ---------------------------------------- Bug #21340: Bump autoconf version to properly handle C23 bool/stdbool defines https://bugs.ruby-lang.org/issues/21340 * Author: christo (Chris Alberti) * Status: Open * ruby -v: 3.4.3, 3.5.0, any built with GCC 15 (so C23) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Right now if I install a recent release using rbenv or asdf, or manually download the latest release 3.4.3 or the preview 3.5.0, the included `./configure` seems to have been generated by an old version of autoconf. After running `./configure`, I end up with a `config.h` containing `HAVE__BOOL = 1`, but _not_ containing `HAVE_STD_BOOL_H = 1`. If I grab the source from github (latest, or 3.4.3 tag) and run autoconf myself (I'm currently on 2.72), I get a config.h with both `HAVE__BOOL = 1` and `HAVE_STD_BOOL_H = 1` defined. This ends up meaning that in the official releases, Ruby's internal/stdbool.h skips using <stdbool.h> and moves on to defining bool/true/false itself. This is not valid as of C23 (which is now default in GCC 15). On my end I found this because I was seeing build failures in the geoip2_compat gem related to issues with the bool type definition on GCC 15. I submitted a patch to the gem's repo for a workaround (include <stdbool.h> before ruby.h), but this might come back to bite other native extension gem compiles as well. It looks like autoconf was patched to fix the HAVE_STD_BOOL_H define for C23 in [this commit](https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=…. I can tell that the ./configure included in the official ruby releases was created with an older version of autoconf because I still see the line: ``` Check for stdbool.h that conforms to C99 ``` rather than the updated version (which appears in my ./configure created with autoconf 2.72) ``` Check for stdbool.h that conforms to C99 or later ``` I'd happily submit a PR if the setup around packaging the official releases is public and someone can point me to it! I wasn't able to find it on a quick search. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:122208] [Ruby Bug#21354] Symbol#to_proc is not ractor safe
by luke-gru (Luke Gruber) 14 Jul '25

14 Jul '25

Issue #21354 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21354: Symbol#to_proc is not ractor safe https://bugs.ruby-lang.org/issues/21354 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- There is caching in `Symbol#to_proc` (`rb_sym_to_proc`) that makes the assumption that we're always in the main ractor. With multiple ractors, this caching logic is not ractor-safe in that cached procs created in one ractor can leak into other ractors. In a debug build, this results in a `ractor_confirm_belonging` assertion failure. Ruby code that reproduces the issue: ```ruby :inspect.to_proc Ractor.new do :inspect.to_proc end.take ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-core:122519] [Ruby Bug#21439] Crash with PM_SPLAT_NODE compiler error (Prism)
by bendrissou (Bachir Bendrissou) 14 Jul '25

14 Jul '25

Issue #21439 has been reported by bendrissou (Bachir Bendrissou). ---------------------------------------- Bug #21439: Crash with PM_SPLAT_NODE compiler error (Prism) https://bugs.ruby-lang.org/issues/21439 * Author: bendrissou (Bachir Bendrissou) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi Ruby team, I'm encountering a crash when using a splat (*) on the left-hand side of a for loop in the latest Ruby build from master. The error occurs during compilation, and seems related to Prism’s handling of PM_SPLAT_NODE. ### Input The following minimal script crashes: ``` for *y in [4, 5] p y end ``` ### Expected Output ``` [4] [5] ``` ### Actual Output ``` bug-1.rb: [BUG] Unexpected node type for index in for node: PM_SPLAT_NODE ruby 3.5.0dev (2025-06-11T18:07:43Z master 970813d982) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000720 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /lib/x86_64-linux-gnu/libasan.so.5(__interceptor_backtrace+0x40) [0x7f13b793bd40] ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4022 /home/ruby/build/ruby(rb_print_backtrace+0x11) [0x558d33041da9] ../vm_dump.c:843 /home/ruby/build/ruby(rb_vm_bugreport) ../vm_dump.c:1175 /home/ruby/build/ruby(rb_bug_without_die_internal+0xc5) [0x558d32704b21] ../error.c:1097 /home/ruby/build/ruby(rb_bug) ../error.c:1115 /home/ruby/build/ruby(pm_compile_for_node_index+0x117) [0x558d32ee742c] ../prism_compile.c:5340 /home/ruby/build/ruby(pm_compile_scope_node) ../prism_compile.c:6911 /home/ruby/build/ruby(pm_compile_node+0x1b50) [0x558d32e88490] ../prism_compile.c:10201 /home/ruby/build/ruby(pm_iseq_compile_node+0x437) [0x558d32eea437] ../prism_compile.c:10512 /home/ruby/build/ruby(pm_iseq_new_with_opt_try+0x3e) [0x558d32824c5e] ../iseq.c:1050 /home/ruby/build/ruby(rb_protect+0x30f) [0x558d327183ff] ../eval.c:1059 /home/ruby/build/ruby(pm_iseq_new_with_opt+0x482) [0x558d32832c12] ../iseq.c:1103 /home/ruby/build/ruby(pm_new_child_iseq+0x19a) [0x558d32dbdc7a] ../prism_compile.c:1261 /home/ruby/build/ruby(pm_compile_node+0x15296) [0x558d32e9bbd6] ../prism_compile.c:9199 /home/ruby/build/ruby(pm_compile_node+0x529d) [0x558d32e8bbdd] ../prism_compile.c:10330 /home/ruby/build/ruby(pm_compile_scope_node+0x3f42) [0x558d32ee3382] ../prism_compile.c:7012 /home/ruby/build/ruby(pm_compile_node+0x1b50) [0x558d32e88490] ../prism_compile.c:10201 /home/ruby/build/ruby(APPEND_LIST+0x0) [0x558d32eea2a4] ../prism_compile.c:10502 /home/ruby/build/ruby(pm_iseq_compile_node) ../prism_compile.c:10506 /home/ruby/build/ruby(pm_iseq_new_with_opt_try+0x3e) [0x558d32824c5e] ../iseq.c:1050 /home/ruby/build/ruby(rb_protect+0x30f) [0x558d327183ff] ../eval.c:1059 /home/ruby/build/ruby(pm_iseq_new_with_opt+0x482) [0x558d32832c12] ../iseq.c:1103 /home/ruby/build/ruby(pm_iseq_new_main+0xbc) [0x558d328332ac] ../iseq.c:951 /home/ruby/build/ruby(process_options+0x2d32) [0x558d329d2b12] ../ruby.c:2641 /home/ruby/build/ruby(ruby_process_options+0x3f0) [0x558d329d5290] ../ruby.c:3199 /home/ruby/build/ruby(ruby_options+0x2a7) [0x558d32715407] ../eval.c:117 /home/ruby/build/ruby(rb_main+0x19) [0x558d327067ff] ../main.c:42 /home/ruby/build/ruby(main) ../main.c:62 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f13b7487083] /home/ruby/build/ruby(_start) [0x558d32707dce] -- Other runtime information ----------------------------------------------- * Loaded script: bug-1.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 Aborted ``` ### Environment Ruby version: `ruby 3.5.0dev (2025-06-11 commit 970813d982) +PRISM` Platform: `x86_64-linux` Built from source using latest master Parser backend: `Prism (default)` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:122409] [Ruby Bug#21395] Please backport 8d49c05c134702c321198b70fbbf34dd80cc1ba6
by mame (Yusuke Endoh) 14 Jul '25

14 Jul '25

Issue #21395 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21395: Please backport 8d49c05c134702c321198b70fbbf34dd80cc1ba6 https://bugs.ruby-lang.org/issues/21395 * Author: mame (Yusuke Endoh) * Status: Closed * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- In Ruby 3.4, debug.gem raises an exception when stepping into a rescue clause: https://github.com/ruby/debug/pull/1142 I discussed with @ko1, and we decided to resolve this by modifying `rb_debug_inspector_backtrace_locations` to return a raw array of `Thread::Backtrace::Location`. This ticket is to request backporting commit:8d49c05c134702c321198b70fbbf34dd80cc1ba6, which implements that change, into Ruby 3.4. --- As a record, here is a more detailed explanation of the issue: Starting from Ruby 3.4, rescue and ensure frames have been excluded from backtraces (see #20275). This change broke the assumption of the debug inspector API. The debug inspector API is designed to be used as follows: 1. Obtain an array of `Thread::Backtrace::Location` using `rb_debug_inspector_backtrace_locations` 2. For each index in that array, obtain more detailed information using functions like `rb_debug_inspector_frame_binding_get(index)` Due to the changes in #20275, rescue/ensure frames were removed from the array returned by `rb_debug_inspector_backtrace_locations`. As a result, the indices in this array became inconsistent with the indices expected by `rb_debug_inspector_frame_binding_get(index)` and similar functions. There are two possible directions for fixing this: 1. Modify `rb_debug_inspector_backtrace_locations` to return the raw backtrace without removing rescue/ensure frames. 2. Modify `rb_debug_inspector_frame_binding_get(index)` to take into account the removal of rescue/ensure frames and return the corresponding data accordingly. @ko1 is interested in trying (2) in the future, but for now, commit 8d49c05c134702c321198b70fbbf34dd80cc1ba6 implements the simpler fix, (1). -- https://bugs.ruby-lang.org/

3 2