January 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:124359] [Ruby Misc#21804] Getting setup-ruby Earlier
by koic (Koichi ITO) 03 Feb '26

03 Feb '26

Issue #21804 has been reported by koic (Koichi ITO). ---------------------------------------- Misc #21804: Getting setup-ruby Earlier https://bugs.ruby-lang.org/issues/21804 * Author: koic (Koichi ITO) * Status: Open ---------------------------------------- ruby/setup-ruby is commonly used for development in OSS projects and real-world Rails applications. https://github.com/ruby/setup-ruby This is not specific to Ruby 4.0.0. There is often a delay between a Ruby release and the availability of the corresponding version in setup-ruby. setup-ruby is maintained by the ruby organization and may take a few days to become available after a Ruby release. In contrast, ruby-build is maintained by the rbenv organization and tends to become available shortly after a Ruby release. This makes it easier to start using new Ruby versions immediately. If setup-ruby maintained by the ruby organization were released shortly after a Ruby release, users could start using new Ruby versions sooner. It is difficult to determine whether this issue should be registered on bugs.ruby-lang.org. Since setup-ruby is maintained by the ruby organization, this issue is being opened to raise awareness of the situation. If this is not appropriate, please feel free to close it. Thank you for your continued maintenance and for releasing Ruby. -- https://bugs.ruby-lang.org/

9 17

[ruby-core:123681] [Ruby Bug#21669] Thoroughly implement void value expression check
by mame (Yusuke Endoh) 03 Feb '26

03 Feb '26

Issue #21669 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21669: Thoroughly implement void value expression check https://bugs.ruby-lang.org/issues/21669 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A void-value-expression check is a syntax check that raises a `SyntaxError` if an expression that cannot grammatically return a value (a "void value expression," such as a `return` expression) appears in a context where a value is expected (e.g., the right-hand side of an assignment, the argument of a method call, etc.). A typical example rejected by this check is `x = return`. However, it has become clear that this check is incomplete. This ticket summarizes the results of a discussion with @matz at the hackathon before RubyWorld Conference today. ## 1\. Expressions containing branches @matz said that an expression containing branches should be considered a void value expression only if it can be grammatically determined that all possible branches do not return a value. Based on this, both parse.y and prism currently reject the following code with a "void value expression" `SyntaxError`, but it should be accepted: ```ruby x = begin raise return rescue "OK" else return end # Expected: Code parses and executes successfully. # Actual: Rejected with "unexpected void value expression" SyntaxError. ``` Reason: The `rescue` clause can return a value ("OK"), so the entire `begin` expression is not void. Conversely, the following code is currently accepted by both parse.y and prism, but it should be rejected: ```ruby x = begin foo rescue return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Reason: This expression always does `return`, so it is void whether `foo` raises an exception or not. Furthermore, `case` expressions must also be rejected similarly when all branches are void: ```ruby x = case when 1; return when 2; return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that `if` expressions appear to be implemented correctly as intended: ```ruby x = if rand < 0.5 return else return end # Expected: Rejected with SyntaxError. # Actual: Rejected. (OK!) ``` ## 2\. Statement lists containing a void value expression @matz also said that if a statements node contains a void value expression, the entire statement list should be treated as a void value expression, even if the void expression is not the last one. Therefore, the following code is currently accepted but should be rejected: ```ruby x = begin return "NG" end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` The same applies to branches within other expressions: ```ruby x = if rand < 0.5 return "NG" else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that if a return statement is inside a branch, that statement cannot be considered a void value expression, so the entire expression also cannot be a void value expression. ```ruby x = begin return if true "NG" end # Expected: Code parses and executes. # Actual: Code parses and executes as expected. (OK!) ``` --- This is considered a bug, but if it causes practical compatibility issues, it may be necessary to plan a migration path or revisit the specifications. (Both prism and parse.y need to be fixed, but I'll assign it to the prism team for now.) -- https://bugs.ruby-lang.org/

6 15

[ruby-core:124638] [Ruby Bug#21854] ruby-prof breaks on 4.0.1
by cfis (Charlie Savage) 31 Jan '26

31 Jan '26

Issue #21854 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21854: ruby-prof breaks on 4.0.1 https://bugs.ruby-lang.org/issues/21854 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ruby-prof breaks on 4.0.1 with segmentation faults when measuring memory. See: https://github.com/ruby-prof/ruby-prof/actions/runs/21465420365/job/6182646… (note failures for ruby 3.x are some test that fail, not segementation faults). Tracking this down, one test that fails measure memory (see traceback below). That way that works: * Get a tracearg event (https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_profile…) * Get a measurement - time, memory, etc. - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * Get the tracearg object - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * Call rb_obj_memsize_of - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * For a T_DATA object in gc.c > case T_DATA: > size += rb_objspace_data_type_memsize(obj); > break; > Then segmentation fault. Running in debugger: ``` RTYPEDDATA_TYPE(obj) 0x332d747365676964 {wrap_struct_name=??? function={dmark=??? dfree=??? dsize=??? ...} parent=??? ...} wrap_struct_name: <Unable to read memory> function: {dmark=??? dfree=??? dsize=??? ...} parent: <Unable to read memory> data: <Unable to read memory> flags: <Unable to read memory> ``` It sure seems like the object that was provide by tracearg has been garbage collected and is no longer valid. Here is the traceback. This is from a MSVC build, but you can see in the gitlab pipelines the same happens on Ubuntu. ```bash -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF817DA1C44] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF814F2BC5F] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_print_backtrace+0x3e) [0x00007FFEEBB01F92] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1129 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_bugreport+0x223) [0x00007FFEEBB021BB] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1453 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_bug_for_fatal_signal+0x75) [0x00007FFEEB9BE779] C:\Source\ruby-4.0.1-mswin\error.c:1131 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(sigsegv+0x3d) [0x00007FFEEBAFAF91] C:\Source\ruby-4.0.1-mswin\signal.c:948 C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007FF81591E8A4] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(`__scrt_common_main_seh'::`1'::filt$0+0x16) [0x00007FF7B95D1B4C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:304 C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll(_C_specific_handler+0x9d) [0x00007FFFF400F55D] C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007FF817DA62FF] C:\WINDOWS\SYSTEM32\ntdll.dll(RtlLocateExtendedFeature+0x597) [0x00007FF817C52327] C:\WINDOWS\SYSTEM32\ntdll.dll(KiUserExceptionDispatcher+0x2e) [0x00007FF817DA5C3E] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_obj_memsize_of+0x1dc) [0x00007FFEEB9A2C8C] C:\Source\ruby-4.0.1-mswin\gc.c:2351 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(measure_memory+0x51) [0x00007FFFA8427161] C:\Source\ruby-prof\ext\ruby_prof\rp_measure_memory.c:23 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_measure+0x1a) [0x00007FFFA8425D8A] C:\Source\ruby-prof\ext\ruby_prof\rp_measurement.c:38 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_event_hook+0x43) [0x00007FFFA842AC23] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:200 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(tp_call_trace+0x26) [0x00007FFEEBA41E12] C:\Source\ruby-4.0.1-mswin\vm_trace.c:1300 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_hooks_body+0x74) [0x00007FFEEBA3FCA4] C:\Source\ruby-4.0.1-mswin\vm_trace.c:457 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_exec_event_hooks+0x4a) [0x00007FFEEBA40326] C:\Source\ruby-4.0.1-mswin\vm_trace.c:543 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_gc_event_hook+0xc1) [0x00007FFEEB99DE35] C:\Source\ruby-4.0.1-mswin\gc.c:241 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(newobj_of+0x17c) [0x00007FFEEB99C348] C:\Source\ruby-4.0.1-mswin\gc.c:1014 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(typed_data_alloc+0xb6) [0x00007FFEEB9A565A] C:\Source\ruby-4.0.1-mswin\gc.c:1102 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_data_typed_object_zalloc+0x3b) [0x00007FFEEB99D877] C:\Source\ruby-4.0.1-mswin\gc.c:1125 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_managed_id_table_create+0x21) [0x00007FFEEBA2AF2D] C:\Source\ruby-4.0.1-mswin\id_table.c:375 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry_or_negative+0x299) [0x00007FFEEB9C434D] C:\Source\ruby-4.0.1-mswin\vm_method.c:1918 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry+0x9) [0x00007FFEEB9C4081] C:\Source\ruby-4.0.1-mswin\vm_method.c:1937 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_populate_cc+0x2a) [0x00007FFEEB9E1CF2] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2155 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_search_method_slowpath+0x7d) [0x00007FFEEB9D0D21] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2299 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_search_method_slowpath0+0x20) [0x00007FFEEB9E261C] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2321 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x14e) [0x00007FFEEB9E2B2E] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6123 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_protect+0x14a) [0x00007FFEEB9B8DFA] C:\Source\ruby-4.0.1-mswin\eval.c:1127 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_instance+0x58) [0x00007FFFA842C128] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:820 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_class+0x2f) [0x00007FFFA842C19F] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:845 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_other+0xbc) [0x00007FFEEB9D5154] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3976 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc+0x103) [0x00007FFEEB9D4E67] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4057 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method_each_type+0x67b) [0x00007FFEEB9D7503] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4888 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method+0x14c) [0x00007FFEEB9D6E68] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:5052 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_each+0x7f) [0x00007FFEEBA1A083] C:\Source\ruby-4.0.1-mswin\array.c:2754 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_collect+0xa4) [0x00007FFEEBA18F38] C:\Source\ruby-4.0.1-mswin\array.c:3767 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_invoke_proc+0x304) [0x00007FFEEB9DF6D8] C:\Source\ruby-4.0.1-mswin\vm.c:1944 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_invoke_proc+0x95) [0x00007FFEEB9CFCE9] C:\Source\ruby-4.0.1-mswin\vm.c:1967 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_proc_call_kw+0x70) [0x00007FFEEBAADD6C] C:\Source\ruby-4.0.1-mswin\proc.c:1134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_end_procs_chain+0x3d) [0x00007FFEEB9B5B4D] C:\Source\ruby-4.0.1-mswin\eval_jump.c:106 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_exec_end_proc+0x13b) [0x00007FFEEB9B73AF] C:\Source\ruby-4.0.1-mswin\eval_jump.c:122 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_teardown+0x11e) [0x00007FFEEB9B789A] C:\Source\ruby-4.0.1-mswin\eval.c:158 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_cleanup+0x260) [0x00007FFEEB9B6C68] C:\Source\ruby-4.0.1-mswin\eval.c:211 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(ruby_run_node+0x4d) [0x00007FFEEB9B998D] C:\Source\ruby-4.0.1-mswin\eval.c:321 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(wmain+0x52) [0x00007FF7B95D1052] C:\Source\ruby-4.0.1-mswin\main.c:48 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF7B95D126C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x17) [0x00007FF816AEE8D7] ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124563] [Ruby Bug#21840] Locking a mutex can lead to starvation
by luke-gru (Luke Gruber) 29 Jan '26

29 Jan '26

Issue #21840 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21840: Locking a mutex can lead to starvation https://bugs.ruby-lang.org/issues/21840 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: luke-gru (Luke Gruber) * Target version: 4.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Continually locking a mutex `m` can lead to starvation if all other threads are on the waitq of `m`. Let `T` be the thread that keeps on acquiring mutex `m` in a loop. Iteration 1: 1) `T` locks mutex `m` 2) All other threads attempt to acquire `m` and end up on its waitq 3) `T` releases the GVL, doesn't wake any other threads because they're all waiting on `m` 4) `T` returns from the blocking function, resets its `running_time` to 0, acquires the GVL and continues running 5) `T` unlocks `m`. It adds the head of the waitq (`T2`) to the thread readyq. `T` continues running Iteration 2: 1) `T` locks mutex `m` 2) `T` calls a blocking function. This time, it dequeues the readyq (ex: `T2`) and sends it the wakeup signal. `T` runs its blocking function 3) `T2` wakes up, acquires the GVL and attempts to lock mutex `m`. It fails and goes back asleep, putting itself back on the waitq of `m`. 4) `T` returns from the blocking function, sets its `running_time` back to 0, acquires the GVL and keeps running 5) `T` unlocks `m`. It adds the head of the waitq (ex: `T3`) to the end of the thread readyq. `T` continues running. Repeat Iteration 2 except the head of readyq is now `T3` The problem is that `T` can never be pre-empted. Example script: ```ruby m = Mutex.new def fib(n) return n if n <= 1 fib(n - 1) + fib(n - 2) end t1_running = false t1 = Thread.new do t1_running = true loop do fib(20) m.synchronize do $stderr.puts "t1 iter" end end end loop until t1_running 5.times.map do Thread.new do m.synchronize do end end end.each(&:join) ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124518] [Ruby Bug#21836] RUBY_MN_THREADS deadlock and sleep issues
by jpl-coconut (Jacob Lacouture) 27 Jan '26

27 Jan '26

Issue #21836 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21836: RUBY_MN_THREADS deadlock and sleep issues https://bugs.ruby-lang.org/issues/21836 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-11-08) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I created a benchmark for the purpose of testing [a fix](https://github.com/ruby/ruby/pull/15840) for [Issue 21685](https://bugs.ruby-lang.org/issues/21685) The benchmark is inline below and saved as 100usec.rb. It should always take just a bit over 10 seconds, regardless of how many cores or threads are assigned. It should look like this: ``` > time taskset --cpu-list 1 ./ruby 100usec.rb 1 real 0m10.130s user 0m0.094s sys 0m0.218s ``` It works fine with MN_THREADS disabled. However, with RUBY_MN_THREADS=1, I see two separate issues. ### Issue #1 is that when the number of cores is set to more than 1, the benchmark completes too fast. These results are consistent across the ruby versions I tried. I did a little debugging and found that the call to `sleep(0.001)` (1ms) is returning after only 0.000005 seconds (5us). ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1,2 ./ruby 100usec.rb 1 real 0m0.359s user 0m0.075s sys 0m0.134s ``` ### Issue #2 shows up when the number of cores is limited to 1. - On ruby 3.4.7 it runs very slow, about 6x slower than expected. ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1 ./ruby 100usec.rb 1 real 1m2.277s user 0m0.249s sys 0m0.408s ``` - On ruby 4.0.0-preview2 it usually deadlocks, but sometimes it segfaults. ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1 ./ruby ruby/100usec.rb 1 [BUG] unreachable ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +MN +PRISM [aarch64-linux] -- Control frame information ----------------------------------------------- -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- [BUG] Illegal instruction at 0x0000ffff93777250 ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +MN +PRISM [aarch64-linux] Crashed while printing bug report Illegal instruction ``` or ``` > time RUBY_MN_THREADS=1 taskset --cpu-list 1 ./ruby ruby/100usec.rb 1 <<DEADLOCK>> ``` ### The benchmark code (100usec.rb) ``` ruby ITRCOUNT = 10000 def inner_test r, w = IO.pipe reader = Thread.new do ITRCOUNT.times.map {|i| r.getbyte } end ITRCOUNT.times.map {|i| sleep 0.0001 w.write('0') } reader.join end def outer_test(count) count.times.map{|j| Thread.new do inner_test end }.each{|t| t.join} end outer_test(ARGV[0].to_i) ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124629] [Ruby Bug#21850] Can't build on FreeBSD/riscv64
by mengzhuo (Meng Zhuo) 27 Jan '26

27 Jan '26

Issue #21850 has been reported by mengzhuo (Meng Zhuo). ---------------------------------------- Bug #21850: Can't build on FreeBSD/riscv64 https://bugs.ruby-lang.org/issues/21850 * Author: mengzhuo (Meng Zhuo) * Status: Open * ruby -v: 3.3.10 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I try to build on freebsd/riscv64 poudriere but got this error ``` https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: riscv64-unknown-freebsd15.0 Thread model: posix InstalledDir: /nxb-bin/usr/bin generating enc.mk ./enc/make_encmake.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.3.10 (2025-10-23 revision 343ea05002) [riscv64-freebsd15] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000a50 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1613259843 Ruby thread count for this ractor: 1 ``` ---Files-------------------------------- ruby-3.3.10,1 (1).log (163 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124627] [Ruby Bug#21849] Ripper.lex emits two `tstring_content` for single string in edge-case
by Earlopain (Earlopain _) 26 Jan '26

26 Jan '26

Issue #21849 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21849: Ripper.lex emits two `tstring_content` for single string in edge-case https://bugs.ruby-lang.org/issues/21849 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb Ripper.lex('"x#$%"') => [[[1, 0], :on_tstring_beg, "\"", BEG], [[1, 1], :on_tstring_content, "x", BEG], [[1, 2], :on_tstring_content, "\#$%", BEG], [[1, 5], :on_tstring_end, "\"", END]] ``` It seems like ripper sees `#$` and assumes that this is bare interpolation. However, `$%` is not a valid global name. So I think it should instead be a single `tstring_content`: ```rb [[[1, 0], :on_tstring_beg, "\"", BEG], [[1, 1], :on_tstring_content, "x\#@%", BEG], [[1, 5], :on_tstring_end, "\"", END]] ``` I stumbled across this in the prism translator for ripper. Prism only emits a single token for the string. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123920] [Ruby Bug#21715] Miscompilation on x86-64-v2 due to undefined behavior in search_nonascii in string.c
by mjacob (Manuel Jacob) 25 Jan '26

25 Jan '26

Issue #21715 has been reported by mjacob (Manuel Jacob). ---------------------------------------- Bug #21715: Miscompilation on x86-64-v2 due to undefined behavior in search_nonascii in string.c https://bugs.ruby-lang.org/issues/21715 * Author: mjacob (Manuel Jacob) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Building the following Dockerfile fails on a x86-64 machine in the last step (running `make` command): ``` FROM opensuse/leap:16.0 RUN zypper --non-interactive install wget make gcc RUN wget 'https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.7.tar.gz' RUN tar xaf ruby-3.4.7.tar.gz WORKDIR ruby-3.4.7/build RUN ../configure RUN make ``` The failing command (during `make`) is: `./miniruby -I../lib -I. -I.ext/common ../tool/mkconfig.rb -arch=x86_64-linux -version=3.4.7 -install_name=ruby -so_name=ruby -unicode_version=15.0.0 -unicode_emoji_version=15.0 > rbconfig.tmp` Excerpt from the crash report: ``` ../tool/mkconfig.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000ec0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x0000556c2da74760 RBP: 0x0000000000000027 RSP: 0x00007ffd24a195f0 RAX: 0x0000000000000028 RBX: 0x0000556c64acc420 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000000000000014 RSI: 0x00007f49f7d6c123 R8: 0x46ea57707c6b1df2 R9: 0x00007f49f7d6c123 R10: 0x2afb945fcb545f01 R11: 0x0000556c2dc3fe50 R12: 0x00007f49f7d6c263 R13: 0x00007f49f7d6c11b R14: 0x0000556c64bdaa48 R15: 0x00007f49f7d6c25c EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /ruby-3.4.7/build/miniruby(rb_print_backtrace+0x5) [0x556c2db2c1b6] ../vm_dump.c:823 /ruby-3.4.7/build/miniruby(rb_vm_bugreport) ../vm_dump.c:1155 /ruby-3.4.7/build/miniruby(rb_bug_for_fatal_signal+0xf7) [0x556c2d8cdc47] ../error.c:1130 /ruby-3.4.7/build/miniruby(sigsegv+0x42) [0x556c2da58482] ../signal.c:934 /lib64/libc.so.6(__restore_rt+0x0) [0x7f49f7eb2090] /ruby-3.4.7/build/miniruby(search_nonascii+0xcb) [0x556c2da74760] ../string.c:729 /ruby-3.4.7/build/miniruby(coderange_scan) ../string.c:767 /ruby-3.4.7/build/miniruby(rbimpl_fl_unset_raw_raw+0x0) [0x556c2da76874] ../string.c:895 /ruby-3.4.7/build/miniruby(RB_FL_UNSET_RAW) ../include/ruby/internal/fl_type.h:669 /ruby-3.4.7/build/miniruby(RB_ENC_CODERANGE_SET) ../include/ruby/internal/encoding/coderange.h:131 /ruby-3.4.7/build/miniruby(enc_coderange_scan) ../string.c:911 /ruby-3.4.7/build/miniruby(rb_enc_str_coderange) ../string.c:910 /ruby-3.4.7/build/miniruby(is_ascii_string+0x8) [0x556c2da7697e] ../internal/string.h:151 /ruby-3.4.7/build/miniruby(str_do_hash) ../string.c:393 /ruby-3.4.7/build/miniruby(register_fstring) ../string.c:554 /ruby-3.4.7/build/miniruby(rb_enc_literal_str+0x87) [0x556c2da94bb7] ../string.c:12546 /ruby-3.4.7/build/miniruby(parse_static_literal_string+0x38) [0x556c2d875991] ../prism_compile.c:312 /ruby-3.4.7/build/miniruby(pm_compile_node) ../prism_compile.c:10321 /ruby-3.4.7/build/miniruby(pm_compile_node+0x2e65) [0x556c2d875aa5] ../prism_compile.c:10309 /ruby-3.4.7/build/miniruby(pm_compile_conditional+0x18c) [0x556c2d88cfcc] ../prism_compile.c:1053 /ruby-3.4.7/build/miniruby(pm_compile_node+0x42e1) [0x556c2d876f21] ../prism_compile.c:9355 /ruby-3.4.7/build/miniruby(pm_setup_args_core+0xe4) [0x556c2d884304] ../prism_compile.c:1792 /ruby-3.4.7/build/miniruby(pm_setup_args+0x98) [0x556c2d884e98] ../prism_compile.c:1979 /ruby-3.4.7/build/miniruby(pm_compile_call+0x307) [0x556c2d885cf7] ../prism_compile.c:3673 /ruby-3.4.7/build/miniruby(pm_compile_call_node+0x2c6) [0x556c2d872326] ../prism_compile.c:7403 /ruby-3.4.7/build/miniruby(pm_compile_node+0x39dc) [0x556c2d87661c] ../prism_compile.c:8775 /ruby-3.4.7/build/miniruby(pm_compile_node+0x2e65) [0x556c2d875aa5] ../prism_compile.c:10309 /ruby-3.4.7/build/miniruby(pm_compile_conditional+0x18c) [0x556c2d88cfcc] ../prism_compile.c:1053-march=x86-64-v2 /ruby-3.4.7/build/miniruby(pm_compile_node+0x42e1) [0x556c2d876f21] ../prism_compile.c:9355 /ruby-3.4.7/build/miniruby(pm_compile_node+0x2e3a) [0x556c2d875a7a] ../prism_compile.c:10307 /ruby-3.4.7/build/miniruby(pm_compile_scope_node+0x104a) [0x556c2d88f5da] ../prism_compile.c:6991 /ruby-3.4.7/build/miniruby(pm_compile_node+0x35c9) [0x556c2d876209] ../prism_compile.c:10180 /ruby-3.4.7/build/miniruby(APPEND_LIST+0x0) [0x556c2d891e60] ../prism_compile.c:10481 /ruby-3.4.7/build/miniruby(pm_iseq_compile_node) ../prism_compile.c:10485 /ruby-3.4.7/build/miniruby(pm_iseq_new_with_opt_try+0x10) [0x556c2d94c790] ../iseq.c:1042 /ruby-3.4.7/build/miniruby(rb_protect+0xd6) [0x556c2d8db9c6] ../eval.c:1054 /ruby-3.4.7/build/miniruby(pm_iseq_new_with_opt+0x177) [0x556c2d9525c7] ../iseq.c:1095 /ruby-3.4.7/build/miniruby(pm_iseq_new_main+0x85) [0x556c2d952895] ../iseq.c:943 /ruby-3.4.7/build/miniruby(process_options+0x12fd) [0x556c2da519cd] ../ruby.c:2616 /ruby-3.4.7/build/miniruby(ruby_process_options+0x157) [0x556c2da52657] ../ruby.c:3174 /ruby-3.4.7/build/miniruby(ruby_options+0x97) [0x556c2d8da977] ../eval.c:117 /ruby-3.4.7/build/miniruby(rb_main+0x19) [0x556c2d7eb578] ../prism/prism.c:21769 /ruby-3.4.7/build/miniruby(main) ../main.c:68 /lib64/libc.so.6(__libc_start_call_main+0x82) [0x7f49f7e9b340] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7f49f7e9b409] /ruby-3.4.7/build/miniruby(_start+0x25) [0x556c2d7eb5c5] ../main.c:69 ``` The failing instruction at 0x556c2da74760 is: `movdqa xmm0, XMMWORD PTR [rsi+rcx*1]`. At this place, register `rsi` contains 0x7f49f7d6c123, which is the value 0x7f49f7d6c11b of parameter `p` of the function `search_nonascii` + 8, and register `rcx` contains 0. So, the whole instruction means “[move aligned packed integer values](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) from memory at 0x7f49f7d6c123 to register `xmm0`”. The segmentation fault happened because the address is expected to be aligned on a 16-byte boundary, but it is not. The instruction is part of a loop at https://github.com/ruby/ruby/blob/v3_4_7/string.c#L728 that gets auto-vectorized by GCC. On x86-64, * `UNALIGNED_WORD_ACCESS` is `1` * `p` doesn’t get aligned to anything because of `#if !UNALIGNED_WORD_ACCESS` in line 700 * `aligned_ptr(value)` is expanded to `(uintptr_t *)(value)` according to line 723 * `p` is therefore casted to type `uintptr_t *` in line 725 * `uintptr_t` is typedefed to `unsigned long int`, which has alignment of 8 bytes In result, a pointer `p` to potentially unaligned memory is casted to a pointer to a type with alignment of 8 bytes. That is undefined behavior according to C99 6.3.2.3p7: “A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined.”. Compilers can utilize this rule to make the assumption that the pointed-to memory has alignment of 8 bytes. In this case, the GCC loop auto-vectorizer adds code to align the assumedly 8 bytes aligned address to 16 bytes alignment. A subsequent instruction assuming 16 bytes alignment can therefore fail. I could reproduce this crash only on openSUSE Leap 16.0, but not openSUSE Leap 15.6, openSUSE Tumbleweed or Arch Linux, because only the former configured GCC to default to emitting code requiring x86-64-v2. When passing `-march=x86-64-v2` in CFLAGS, the crash happens on all these distributions. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:124475] [Ruby Bug#21832] segfault with argument forwarding, when combined with splat & positional arg
by inopinatus (Joshua GOODALL) 25 Jan '26

25 Jan '26

Issue #21832 has been reported by inopinatus (Joshua GOODALL). ---------------------------------------- Bug #21832: segfault with argument forwarding, when combined with splat & positional arg https://bugs.ruby-lang.org/issues/21832 * Author: inopinatus (Joshua GOODALL) * Status: Open * ruby -v: ruby 4.1.0dev (2026-01-11T15:46:56Z master 61c372a1b7) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A crash occurs when combining (...) arg forwarding, a positional argument, and an array splat. Found with 4.0.0 release, verified on 3.4.8 and 4.1.0dev, does not occur on 3.3.10. One-line crash test: ``` ruby ./ruby -e 'def target(*args) = args; def x = [1]; def forwarder(...); target(*x, 2, ...); end; forwarder(3)' ``` test builds were: * Ruby 4.1.0dev w/clang-1700.6.3.2 on arm64 (macOS Sequoia 15.7.1) * Ruby 3.4.8 w/gcc 13.3.0 on x86_64 (Ubuntu 24.04 LTS) longer test case: ``` ruby class Test def stdargs %w(--verbose) end def func(*args) puts "args: #{args.inspect}" end def test1(...) func("abc", ...) end def test2(...) func(stdargs, "abc", ...) end def test3(...) func(*stdargs, "abc") end def test4(...) func(*stdargs, ...) end def test5(...) func(*stdargs, "abc", ...) end end o = Test.new o.test1("T1") #=> args: ["abc", "T1"] o.test2("T2") #=> args: [["foo"], "abc", "T2"] o.test3("T3") #=> args: ["foo", "abc"] o.test4("T4") #=> args: ["foo", "T4"] o.test5("T5") #=> Expected: ["foo", "abc", "T5"] Actual: crash ``` Crash output: ``` [505] (master) joshua@coltrane:~/src/ruby-src$ ./ruby crash.rb `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. args: ["abc", "T1"] args: [["--verbose"], "abc", "T2"] args: ["--verbose", "abc"] args: ["--verbose", "T4"] crash.rb:28: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.1.0dev (2026-01-11T15:46:56Z master 61c372a1b7) +PRISM [arm64-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:0003 p:0013 s:0017 e:000012 l:y b:0001 METHOD crash.rb:28 c:0002 p:0059 s:0007 E:002508 l:n b:---- EVAL crash.rb:38 [FINISH] c:0001 p:0000 s:0003 E:000010 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- crash.rb:38:in '<main>' crash.rb:28:in 'test5' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000160028078 x1: 0x0000000000000000 x2: 0x0000000000000010 x3: 0x0000000160028078 x4: 0x0000000000000000 x5: 0x000000016d97a670 x6: 0x000000016d97a648 x7: 0x000000016d97a598 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x000000016d97a648 x21: 0x0000000102e9da38 x22: 0x0000000160127f58 x23: 0x000000016d97a670 x24: 0x0000000160028078 x25: 0x000092d100100003 x26: 0x0000000160028060 x27: 0x0000000000000001 x28: 0x0000000000000001 lr: 0x00000001026eab50 fp: 0x000000016d97a5e0 sp: 0x000000016d97a560 -- C level backtrace information ------------------------------------------- /Users/joshua/src/ruby-src/ruby(rb_vm_bugreport+0xbc8) [0x10271b60c] /Users/joshua/src/ruby-src/vm_dump.c:1450 /Users/joshua/src/ruby-src/ruby(rb_vm_bugreport) (null):0 /Users/joshua/src/ruby-src/ruby(rb_bug_for_fatal_signal+0x10c) [0x10254092c] /Users/joshua/src/ruby-src/error.c:1131 /Users/joshua/src/ruby-src/ruby(sigsegv+0x90) [0x102671e70] /Users/joshua/src/ruby-src/signal.c:948 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x196be16a4] /Users/joshua/src/ruby-src/ruby(RB_FL_TEST_RAW+0x0) [0x1026eab50] ./include/ruby/internal/memory.h:759 /Users/joshua/src/ruby-src/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:466 /Users/joshua/src/ruby-src/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:259 /Users/joshua/src/ruby-src/ruby(vm_caller_setup_fwd_args) ./vm_insnhelper.c:3410 /Users/joshua/src/ruby-src/ruby(vm_exec_core+0x12f0) [0x1026ed304] /Users/joshua/src/ruby-src/insns.def:877 /Users/joshua/src/ruby-src/ruby(rb_vm_exec+0x284) [0x1026ea428] /Users/joshua/src/ruby-src/vm.c:2798 /Users/joshua/src/ruby-src/ruby(rb_ec_exec_node+0x8c) [0x10254bb84] /Users/joshua/src/ruby-src/eval.c:283 /Users/joshua/src/ruby-src/ruby(ruby_run_node+0x4c) [0x10254baa4] /Users/joshua/src/ruby-src/eval.c:321 /Users/joshua/src/ruby-src/ruby(rb_main+0x1c) [0x102484980] ./main.c:42 /Users/joshua/src/ruby-src/ruby(main) ./main.c:62 ``` -- https://bugs.ruby-lang.org/

6 7

[ruby-core:124366] [Ruby Bug#21807] ArgumentError is reported when forwarding arguments to method with intermediate optional arguments
by taichi730 (Taichi Ishitani) 25 Jan '26

25 Jan '26

Issue #21807 has been reported by taichi730 (Taichi Ishitani). ---------------------------------------- Bug #21807: ArgumentError is reported when forwarding arguments to method with intermediate optional arguments https://bugs.ruby-lang.org/issues/21807 * Author: taichi730 (Taichi Ishitani) * Status: Open * ruby -v: 3.4.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In Ruby 3.4.x, @ArgumentError@ is reported when forwarding arguments to a method with intermediate optional arguments. How to reproduce: Execute sample below. ``` ruby class Foo def foo(a = nil, b) p a, b end end class Bar def initialize @foo = Foo.new end def bar(...) @foo.foo(...) @foo.foo(...) end end class Baz def initialize @bar = Bar.new end def baz(_a, ...) @bar.bar(...) end end puts RUBY_VERSION baz = Baz.new baz.baz(0, 1) ``` output: <pre> $ RBENV_VERSION=3.4.8 ruby test.rb 3.4.8 nil 1 test.rb:2:in 'foo': wrong number of arguments (given 0, expected 1..2) (ArgumentError) from test.rb:14:in 'Bar#bar' from test.rb:24:in 'Baz#baz' </pre> <pre> $ RBENV_VERSION=3.4.1 ruby test.rb 3.4.1 nil 1 test.rb:2:in 'foo': wrong number of arguments (given 0, expected 1..2) (ArgumentError) from test.rb:14:in 'Bar#bar' from test.rb:24:in 'Baz#baz' </pre> For other Ruby verions (e.g. 4.0.0, 3.3.0), no error is reported. <pre> $ RBENV_VERSION=4.0.0 ruby test.rb 4.0.0 nil 1 nil 1 </pre> <pre> $ RBENV_VERSION=3.3.0 ruby test.rb 3.3.0 nil 1 nil 1 </pre> -- https://bugs.ruby-lang.org/

3 3