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

[ruby-core:112301] [Ruby master Bug#19426] Endless `Range#step` of object with `#succ` method does not work
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #19426 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19426: Endless `Range#step` of object with `#succ` method does not work https://bugs.ruby-lang.org/issues/19426 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Consider this `c` object which hash `#succ` method. ```ruby c = Struct.new(:i) do def succ; self.class.new(i+1); end def <=>(other) i <=> other.i;end end.new(0) ``` This `Range#step` works. ```ruby (c..c.succ).step(1) do |d| p d.i # 0, 1 end ``` But it fails on an endless range. ```ruby (c..).step(1) do |d| p d.i break if d.i > 3 end ``` ``` -:3:in `<=>': undefined method `i' for nil:NilClass (NoMethodError) from -:10:in `step' from -:10:in `<main>' ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120637] [Ruby master Bug#21032] `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path
by byroot (Jean Boussier) 13 Mar '25

13 Mar '25

Issue #21032 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21032: `Module#autoload?` is slow when `$LOAD_PATH` contains a relative path https://bugs.ruby-lang.org/issues/21032 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Reproduction script: ```ruby require 'benchmark' $LOAD_PATH << 'relative-path' autoload :FOO, '/tmp/foo.rb' puts Benchmark.realtime { 500_000.times do Object.autoload?(:FOO) end } ``` The above takes 2.5 to 3 seconds on my machine, but just removing `$LOAD_PATH << 'relative-path'` make it complete in 50ms. It's such a stark difference that I think it is a bug, and it cause Zeitwerk, a very popular gem, to be way slower than it should when the load path contains relative paths. I have a patch for it, that passes all tests, but I'd appreciate some eyes on it: https://github.com/ruby/ruby/pull/12562 cc @fxn -- https://bugs.ruby-lang.org/

5 8

[ruby-core:121312] [Ruby master Bug#18257] rb_mRubyVMFrozenCore is broken by GC run
by hsbt (Hiroshi SHIBATA) 13 Mar '25

13 Mar '25

Issue #18257 has been updated by hsbt (Hiroshi SHIBATA). Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ruby_3_2 commit:b1b983915e109ae78e4e3a5c912f9f9597983641 merged revision(s) commit:647390308239fbf82d159ecd83ed8df090af518d. ---------------------------------------- Bug #18257: rb_mRubyVMFrozenCore is broken by GC run https://bugs.ruby-lang.org/issues/18257#change-112276 * Author: vo.x (Vit Ondruch) * Status: Closed * ruby -v: ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-linux] * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- Testing Ruby with SystemTap on RHEL9 beta following these steps: ~~~ $ stap -v /usr/share/doc/ruby-doc/ruby-exercise.stp & $ ruby -e '[1, 2, 3].push(4)' ~~~ I get the following error: ~~~ /usr/share/rubygems/rubygems/errors.rb:181: [BUG] Segmentation fault at 0x0000000000000014 ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [powerpc64le-linux] -- Control frame information ----------------------------------------------- c:0008 p:0028 s:0032 e:000027 CLASS /usr/share/rubygems/rubygems/errors.rb:181 c:0007 p:0110 s:0025 e:000024 CLASS /usr/share/rubygems/rubygems/errors.rb:153 c:0006 p:0007 s:0022 e:000021 TOP /usr/share/rubygems/rubygems/errors.rb:9 [FINISH] c:0005 p:---- s:0019 e:000018 CFUNC :require c:0004 p:0037 s:0014 e:000013 TOP /usr/share/rubygems/rubygems.rb:19 [FINISH] c:0003 p:---- s:0011 e:000010 CFUNC :require c:0002 p:0012 s:0006 e:000005 TOP <internal:gem_prelude>:2 [FINISH] c:0001 p:0000 s:0003 E:0026c0 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- <internal:gem_prelude>:2:in `<internal:gem_prelude>' <internal:gem_prelude>:2:in `require' /usr/share/rubygems/rubygems.rb:19:in `<top (required)>' /usr/share/rubygems/rubygems.rb:19:in `require' /usr/share/rubygems/rubygems/errors.rb:9:in `<top (required)>' /usr/share/rubygems/rubygems/errors.rb:153:in `<module:Gem>' /usr/share/rubygems/rubygems/errors.rb:181:in `<class:SourceFetchProblem>' -- C level backtrace information ------------------------------------------- /lib64/libruby.so.3.0(0x7fffb3b06ba0) [0x7fffb3b06ba0] /lib64/libruby.so.3.0(0x7fffb38d9680) [0x7fffb38d9680] /lib64/libruby.so.3.0(0x7fffb3a4b9d8) [0x7fffb3a4b9d8] linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0) [0x7fffb3ca0464] [0x7fffb3a67ff8] /lib64/libruby.so.3.0(rb_str_dup+0x130) [0x7fffb3a6b950] /lib64/libruby.so.3.0(rb_class_path+0x3c) [0x7fffb3ac72ac] /lib64/libruby.so.3.0(rb_dtrace_setup+0x134) [0x7fffb3ae46a4] [0x7fffb3ae4a00] [0x7fffb3ae7644] [0x7fffb3aeba5c] /lib64/libruby.so.3.0(rb_vm_exec+0x140) [0x7fffb3af1710] /lib64/libruby.so.3.0(rb_iseq_eval+0x164) [0x7fffb3af29f4] [0x7fffb394ce68] /lib64/libruby.so.3.0(rb_require_string+0x44) [0x7fffb394e7f4] /lib64/libruby.so.3.0(rb_f_require+0x1c) [0x7fffb394e88c] [0x7fffb3acf538] [0x7fffb3ae4900] [0x7fffb3ae7644] [0x7fffb3aeba5c] /lib64/libruby.so.3.0(rb_vm_exec+0x140) [0x7fffb3af1710] /lib64/libruby.so.3.0(rb_iseq_eval+0x164) [0x7fffb3af29f4] [0x7fffb394ce68] /lib64/libruby.so.3.0(rb_require_string+0x44) [0x7fffb394e7f4] /lib64/libruby.so.3.0(rb_f_require+0x1c) [0x7fffb394e88c] [0x7fffb3acf538] [0x7fffb3ae4900] [0x7fffb3ae7644] [0x7fffb3aeba5c] /lib64/libruby.so.3.0(rb_vm_exec+0x140) [0x7fffb3af1710] /lib64/libruby.so.3.0(rb_iseq_eval+0x164) [0x7fffb3af29f4] [0x7fffb3b15f60] [0x7fffb3a4826c] [0x7fffb3a499d8] /lib64/libruby.so.3.0(ruby_process_options+0x158) [0x7fffb3a4a778] /lib64/libruby.so.3.0(ruby_options+0xf4) [0x7fffb38e5904] [0x11a360a60] [0x7fffb35d7ca4] [0x7fffb35d7e80] -- Other runtime information ----------------------------------------------- * Loaded script: ruby * Loaded features: 0 enumerator.so 1 thread.rb 2 rational.so 3 complex.so 4 ruby2_keywords.rb 5 /usr/lib64/ruby/enc/encdb.so 6 /usr/lib64/ruby/enc/trans/transdb.so 7 /usr/lib64/ruby/rbconfig.rb 8 /usr/share/rubygems/rubygems/compatibility.rb 9 /usr/share/rubygems/rubygems/defaults.rb 10 /usr/share/rubygems/rubygems/deprecate.rb * Process memory map: 11a360000-11a370000 r-xp 00000000 fd:00 34097694 /usr/bin/ruby 11a370000-11a380000 r--p 00000000 fd:00 34097694 /usr/bin/ruby 11a380000-11a390000 rw-p 00010000 fd:00 34097694 /usr/bin/ruby 1000d490000-1000d6b0000 rw-p 00000000 00:00 0 [heap] 7fffaf470000-7fffaf8d0000 r--s 00000000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffaf8d0000-7fffaf8f0000 r--s 00000000 fd:00 34097694 /usr/bin/ruby 7fffaf8f0000-7fffaf900000 r-xp 00000000 fd:00 100999014 /usr/lib64/ruby/enc/trans/transdb.so 7fffaf900000-7fffaf910000 r--p 00000000 fd:00 100999014 /usr/lib64/ruby/enc/trans/transdb.so 7fffaf910000-7fffaf920000 rw-p 00000000 00:00 0 7fffaf920000-7fffaf930000 r-xp 00000000 fd:00 67811915 /usr/lib64/ruby/enc/encdb.so 7fffaf930000-7fffaf940000 r--p 00000000 fd:00 67811915 /usr/lib64/ruby/enc/encdb.so 7fffaf940000-7fffaf950000 rw-p 00000000 00:00 0 7fffaf950000-7fffaf960000 ---p 00000000 00:00 0 7fffaf960000-7fffafa10000 rw-p 00000000 00:00 0 7fffafa10000-7fffafa20000 ---p 00000000 00:00 0 7fffafa20000-7fffafad0000 rw-p 00000000 00:00 0 7fffafad0000-7fffafae0000 ---p 00000000 00:00 0 7fffafae0000-7fffafb90000 rw-p 00000000 00:00 0 7fffafb90000-7fffafba0000 ---p 00000000 00:00 0 7fffafba0000-7fffafc50000 rw-p 00000000 00:00 0 7fffafc50000-7fffafc60000 ---p 00000000 00:00 0 7fffafc60000-7fffafd10000 rw-p 00000000 00:00 0 7fffafd10000-7fffafd20000 ---p 00000000 00:00 0 7fffafd20000-7fffafdd0000 rw-p 00000000 00:00 0 7fffafdd0000-7fffafde0000 ---p 00000000 00:00 0 7fffafde0000-7fffafe90000 rw-p 00000000 00:00 0 7fffafe90000-7fffafea0000 ---p 00000000 00:00 0 7fffafea0000-7fffaff50000 rw-p 00000000 00:00 0 7fffaff50000-7fffaff60000 ---p 00000000 00:00 0 7fffaff60000-7fffb0010000 rw-p 00000000 00:00 0 7fffb0010000-7fffb0020000 ---p 00000000 00:00 0 7fffb0020000-7fffb00d0000 rw-p 00000000 00:00 0 7fffb00d0000-7fffb00e0000 ---p 00000000 00:00 0 7fffb00e0000-7fffb0190000 rw-p 00000000 00:00 0 7fffb0190000-7fffb01a0000 ---p 00000000 00:00 0 7fffb01a0000-7fffb0250000 rw-p 00000000 00:00 0 7fffb0250000-7fffb0260000 ---p 00000000 00:00 0 7fffb0260000-7fffb0310000 rw-p 00000000 00:00 0 7fffb0310000-7fffb0320000 ---p 00000000 00:00 0 7fffb0320000-7fffb03d0000 rw-p 00000000 00:00 0 7fffb03d0000-7fffb03e0000 ---p 00000000 00:00 0 7fffb03e0000-7fffb0490000 rw-p 00000000 00:00 0 7fffb0490000-7fffb04a0000 ---p 00000000 00:00 0 7fffb04a0000-7fffb0550000 rw-p 00000000 00:00 0 7fffb0550000-7fffb0560000 ---p 00000000 00:00 0 7fffb0560000-7fffb0610000 rw-p 00000000 00:00 0 7fffb0610000-7fffb0620000 ---p 00000000 00:00 0 7fffb0620000-7fffb06d0000 rw-p 00000000 00:00 0 7fffb06d0000-7fffb06e0000 ---p 00000000 00:00 0 7fffb06e0000-7fffb0790000 rw-p 00000000 00:00 0 7fffb0790000-7fffb07a0000 ---p 00000000 00:00 0 7fffb07a0000-7fffb0850000 rw-p 00000000 00:00 0 7fffb0850000-7fffb0860000 ---p 00000000 00:00 0 7fffb0860000-7fffb0910000 rw-p 00000000 00:00 0 7fffb0910000-7fffb0920000 ---p 00000000 00:00 0 7fffb0920000-7fffb09d0000 rw-p 00000000 00:00 0 7fffb09d0000-7fffb09e0000 ---p 00000000 00:00 0 7fffb09e0000-7fffb0a90000 rw-p 00000000 00:00 0 7fffb0a90000-7fffb0aa0000 ---p 00000000 00:00 0 7fffb0aa0000-7fffb0b50000 rw-p 00000000 00:00 0 7fffb0b50000-7fffb0b60000 ---p 00000000 00:00 0 7fffb0b60000-7fffb0c10000 rw-p 00000000 00:00 0 7fffb0c10000-7fffb0c20000 ---p 00000000 00:00 0 7fffb0c20000-7fffb0cd0000 rw-p 00000000 00:00 0 7fffb0cd0000-7fffb0ce0000 ---p 00000000 00:00 0 7fffb0ce0000-7fffb0d90000 rw-p 00000000 00:00 0 7fffb0d90000-7fffb0da0000 ---p 00000000 00:00 0 7fffb0da0000-7fffb0e50000 rw-p 00000000 00:00 0 7fffb0e50000-7fffb0e60000 ---p 00000000 00:00 0 7fffb0e60000-7fffb0f10000 rw-p 00000000 00:00 0 7fffb0f10000-7fffb0f20000 ---p 00000000 00:00 0 7fffb0f20000-7fffb0fd0000 rw-p 00000000 00:00 0 7fffb0fd0000-7fffb0fe0000 ---p 00000000 00:00 0 7fffb0fe0000-7fffb1090000 rw-p 00000000 00:00 0 7fffb1090000-7fffb10a0000 ---p 00000000 00:00 0 7fffb10a0000-7fffb32e0000 rw-p 00000000 00:00 0 7fffb32e0000-7fffb3340000 r--p 00000000 fd:00 33555845 /usr/lib/locale/en_US.utf8/LC_CTYPE 7fffb3340000-7fffb3420000 r-xp 00000000 fd:00 67172714 /usr/lib64/libm.so.6 7fffb3420000-7fffb3430000 r--p 000d0000 fd:00 67172714 /usr/lib64/libm.so.6 7fffb3430000-7fffb3440000 rw-p 000e0000 fd:00 67172714 /usr/lib64/libm.so.6 7fffb3440000-7fffb3480000 r-xp 00000000 fd:00 67172871 /usr/lib64/libcrypt.so.2.0.0 7fffb3480000-7fffb3490000 r--p 00030000 fd:00 67172871 /usr/lib64/libcrypt.so.2.0.0 7fffb3490000-7fffb34a0000 rw-p 00000000 00:00 0 7fffb34a0000-7fffb3540000 r-xp 00000000 fd:00 67172912 /usr/lib64/libgmp.so.10.4.0 7fffb3540000-7fffb3550000 r--p 00090000 fd:00 67172912 /usr/lib64/libgmp.so.10.4.0 7fffb3550000-7fffb3560000 rw-p 000a0000 fd:00 67172912 /usr/lib64/libgmp.so.10.4.0 7fffb3560000-7fffb3580000 r-xp 00000000 fd:00 67172832 /usr/lib64/libz.so.1.2.11 7fffb3580000-7fffb3590000 r--p 00010000 fd:00 67172832 /usr/lib64/libz.so.1.2.11 7fffb3590000-7fffb35a0000 rw-p 00020000 fd:00 67172832 /usr/lib64/libz.so.1.2.11 7fffb35a0000-7fffb37e0000 r-xp 00000000 fd:00 67172711 /usr/lib64/libc.so.6 7fffb37e0000-7fffb37f0000 r--p 00230000 fd:00 67172711 /usr/lib64/libc.so.6 7fffb37f0000-7fffb3800000 rw-p 00240000 fd:00 67172711 /usr/lib64/libc.so.6 7fffb3800000-7fffb3c30000 r-xp 00000000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c30000-7fffb3c40000 ---p 00430000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c40000-7fffb3c50000 r--p 00430000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c50000-7fffb3c60000 rw-p 00440000 fd:00 67811909 /usr/lib64/libruby.so.3.0.2 7fffb3c60000-7fffb3c70000 rw-p 00000000 00:00 0 7fffb3c70000-7fffb3c80000 r--s 00000000 fd:00 100673889 /usr/lib64/gconv/gconv-modules.cache 7fffb3c80000-7fffb3ca0000 r--p 00000000 00:00 0 [vvar] 7fffb3ca0000-7fffb3cb0000 r-xp 00000000 00:00 0 [vdso] 7fffb3cb0000-7fffb3d00000 r-xp 00000000 fd:00 67172707 /usr/lib64/ld64.so.2 7fffb3d00000-7fffb3d10000 r--p 00040000 fd:00 67172707 /usr/lib64/ld64.so.2 7fffb3d10000-7fffb3d20000 rw-p 00050000 fd:00 67172707 /usr/lib64/ld64.so.2 7fffdee00000-7fffdf600000 rw-p 00000000 00:00 0 [stack] ~~~ This should be the full BT: ~~~ (gdb) bt #0 0x00007fffa5711550 in uleb128 (p=0x10039917f10) at addr2line.c:200 #1 di_read_die (reader=reader@entry=0x10039917eb8, die=die@entry=0x10039917dc8) at addr2line.c:1343 #2 0x00007fffa5714574 in debug_info_read (offset=<optimized out>, lines=<optimized out>, traces=<optimized out>, num_traces=<optimized out>, reader=<optimized out>) at addr2line.c:1630 #3 fill_lines (num_traces=num_traces@entry=39, traces=traces@entry=0x7fffa585d778 <trace>, check_debuglink=check_debuglink@entry=0, objp=objp@entry=0x10039919370, lines=lines@entry=0x100399756f0, offset=<optimized out>, offset@entry=0) at addr2line.c:1887 #4 0x00007fffa5714f28 in follow_debuglink (offset=0, lines=0x100399756f0, objp=0x10039919370, traces=<optimized out>, num_traces=39, debuglink=0x7fffa14e01e4 "ruby-3.0.2-155.el9.ppc64le.debug") at addr2line.c:574 #5 fill_lines (num_traces=num_traces@entry=39, traces=traces@entry=0x7fffa585d778 <trace>, check_debuglink=check_debuglink@entry=1, objp=0x10039919370, objp@entry=0x100399193f0, lines=lines@entry=0x100399756f0, offset=<optimized out>, offset@entry=-1) at addr2line.c:1925 #6 0x00007fffa571576c in rb_dump_backtrace_with_lines (num_traces=<optimized out>, traces=0x7fffa585d778 <trace>) at addr2line.c:2286 #7 0x00007fffa5706bac in rb_print_backtrace () at vm_dump.c:760 #8 rb_vm_bugreport (ctx=<optimized out>) at vm_dump.c:998 #9 0x00007fffa54d9680 in rb_bug_for_fatal_signal (default_sighandler=0x0, sig=<optimized out>, ctx=0x100399197c0, fmt=0x7fffa574e8f0 "Segmentation fault at %p") at error.c:786 #10 0x00007fffa564b9d8 in sigsegv (sig=<optimized out>, info=0x1003991a540, ctx=0x100399197c0) at signal.c:960 #11 <signal handler called> #12 0x00007fffa5667ff8 in str_new_frozen_buffer (klass=klass@entry=1100477014720, orig=orig@entry=1100476844400, copy_encoding=copy_encoding@entry=1) at string.c:1329 #13 0x00007fffa566b950 in str_new_frozen (orig=1100476844400, klass=1100477014720) at string.c:1297 #14 str_duplicate_setup (dup=1100478149120, str=1100476844400, klass=1100477014720) at string.c:1570 #15 str_duplicate (str=1100476844400, klass=1100477014720) at string.c:1602 #16 rb_str_dup (str=1100476844400) at string.c:1608 #17 0x00007fffa56c72ac in rb_class_path (klass=1100476844480) at variable.c:173 #18 0x00007fffa56e46a4 in rb_dtrace_setup (ec=<optimized out>, klass=1100476844480, id=159, args=0x7fffe9d953d8) at vm.c:449 #19 0x00007fffa56e4a00 in vm_call_cfunc_with_frame (ec=<optimized out>, reg_cfp=0x7fffa4ecfe50, calling=<optimized out>) at vm_insnhelper.c:2916 #20 0x00007fffa56e7644 in vm_sendish (ec=0x10039811cf0, reg_cfp=0x7fffa4ecfe50, cd=0x100399a8db0, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:336 #21 0x00007fffa56eba5c in vm_exec_core (ec=0x10039811cf0, initial=<optimized out>, initial@entry=0) at insns.def:789 #22 0x00007fffa56f1710 in rb_vm_exec (ec=0x10039811cf0, mjit_enable_p=<optimized out>) at vm.c:2172 #23 0x00007fffa56f29f4 in rb_iseq_eval (iseq=0x100398aa7c0) at vm.c:2409 #24 0x00007fffa554ce68 in load_iseq_eval (fname=1100477137480, ec=0x10039811cf0) at load.c:594 #25 require_internal (ec=ec@entry=0x10039811cf0, fname=<optimized out>, fname@entry=1100476430040, exception=exception@entry=1) at load.c:1065 #26 0x00007fffa554e7f4 in rb_require_string (fname=1100476430040) at load.c:1142 #27 0x00007fffa554e88c in rb_f_require (obj=<optimized out>, fname=<optimized out>) at load.c:838 #28 0x00007fffa56cf538 in ractor_safe_call_cfunc_1 (recv=<optimized out>, argc=<optimized out>, argv=<optimized out>, func=<optimized out>) at vm_insnhelper.c:2750 #29 0x00007fffa56e4900 in vm_call_cfunc_with_frame (ec=0x10039811cf0, reg_cfp=0x7fffa4ecff30, calling=<optimized out>) at vm_insnhelper.c:2926 #30 0x00007fffa56e7644 in vm_sendish (ec=0x10039811cf0, reg_cfp=0x7fffa4ecff30, cd=0x10039901e50, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:336 #31 0x00007fffa56eba5c in vm_exec_core (ec=0x10039811cf0, initial=<optimized out>, initial@entry=0) at insns.def:789 #32 0x00007fffa56f1710 in rb_vm_exec (ec=0x10039811cf0, mjit_enable_p=<optimized out>) at vm.c:2172 #33 0x00007fffa56f29f4 in rb_iseq_eval (iseq=0x1003981b9a8) at vm.c:2409 #34 0x00007fffa554ce68 in load_iseq_eval (fname=1100476613760, ec=0x10039811cf0) at load.c:594 #35 require_internal (ec=ec@entry=0x10039811cf0, fname=<optimized out>, fname@entry=1100476614040, exception=exception@entry=1) at load.c:1065 #36 0x00007fffa554e7f4 in rb_require_string (fname=1100476614040) at load.c:1142 #37 0x00007fffa554e88c in rb_f_require (obj=<optimized out>, fname=<optimized out>) at load.c:838 #38 0x00007fffa56cf538 in ractor_safe_call_cfunc_1 (recv=<optimized out>, argc=<optimized out>, argv=<optimized out>, func=<optimized out>) at vm_insnhelper.c:2750 #39 0x00007fffa56e4900 in vm_call_cfunc_with_frame (ec=0x10039811cf0, reg_cfp=0x7fffa4ecffa0, calling=<optimized out>) at vm_insnhelper.c:2926 #40 0x00007fffa56e7644 in vm_sendish (ec=0x10039811cf0, reg_cfp=0x7fffa4ecffa0, cd=0x10039970580, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:336 #41 0x00007fffa56eba5c in vm_exec_core (ec=0x10039811cf0, initial=<optimized out>, initial@entry=0) at insns.def:789 #42 0x00007fffa56f1710 in rb_vm_exec (ec=0x10039811cf0, mjit_enable_p=<optimized out>) at vm.c:2172 #43 0x00007fffa56f29f4 in rb_iseq_eval (iseq=0x100398489f8) at vm.c:2409 #44 0x00007fffa5715f60 in rb_load_with_builtin_functions (feature_name=0x7fffa57b61c0 "gem_prelude", table=0x0) at builtin.c:54 #45 0x00007fffa564826c in ruby_init_prelude () at ruby.c:1498 #46 ruby_opt_init (opt=0x7fffe9d98690) at ruby.c:1521 #47 ruby_opt_init (opt=0x7fffe9d98690) at ruby.c:1506 #48 0x00007fffa56499d8 in process_options (argc=0, argc@entry=3, argv=0x7fffe9d98f10, argv@entry=0x7fffe9d98ef8, opt=opt@entry=0x7fffe9d98690) at ruby.c:1951 #49 0x00007fffa564a778 in ruby_process_options (argc=<optimized out>, argv=0x7fffe9d98ef8) at ruby.c:230 #50 0x00007fffa54e5904 in ruby_options (argc=<optimized out>, argv=0x7fffe9d98ef8) at eval.c:138 #51 0x000000010b860a60 in main (argc=<optimized out>, argv=<optimized out>) at ./main.c:50 ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120949] [Ruby master Bug#21129] Backporting strscan fix in Ruby 3.2
by andrykonchin (Andrew Konchin) 12 Mar '25

12 Mar '25

Issue #21129 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21129: Backporting strscan fix in Ruby 3.2 https://bugs.ruby-lang.org/issues/21129 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.7 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- An `strscan` version shipped with Ruby 3.2 (`strscan` v3.0.5) has a bug. It was fixed long time ago in `strscan` v3.0.7 (in https://github.com/ruby/strscan/pull/61) but reported recently again in https://github.com/ruby/strscan/issues/132. Ruby 3.2 AFAIK is still normally supported. So does it make sense to have a new Ruby 3.2.x patch level release with `strscan` v3.0.7? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120232] [Ruby master Misc#20951] Confusing handling of timezone object's `#utc_to_local` results
by andrykonchin (Andrew Konchin) 12 Mar '25

12 Mar '25

Issue #20951 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #20951: Confusing handling of timezone object's `#utc_to_local` results https://bugs.ruby-lang.org/issues/20951 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- I am looking into the timezone object feature (that is supported by various Time class methods) now and I am confused by the current implementation. Specifically, how a time-like object **that is not inherited from the Time class** is handled. A time-like object is returned for instance from the timezone object's `#utc_to_local` method. The documentation states that: > A Time-like object is a container object capable of interfacing with timezone libraries for timezone conversion. Also > The zone value may be an object responding to certain timezone methods, an instance of Timezone and TZInfo for example. And indeed the `TZInfo::Timezone` class works as expected. But when I try to use for time-like objects a brand new class not inherited from Time - it works incorrectly. Let's consider an example with `TZInfo::Timezone`: ```ruby require 'tzinfo' zone = TZInfo::Timezone.get("Europe/Kiev") # UTC+2 time = Time.now.utc puts time.to_i # 1734107333 puts Time.now(in: zone) # 2024-12-13 18:28:53 +0200 puts zone.utc_to_local(time) # 2024-12-13 18:28:53 +0200 puts zone.utc_to_local(time).to_i # 1734107333 ``` And now an example with a brand new class. I make an assumption, that as far as `zone.utc_to_local(time).to_i` doesn't change Unix timestamp (it equals `time.to_i`, that's 1734107333), so in a new class also `#utc_to_local` should return not modified value too. ```ruby TimeObj = Struct.new(:year, :mon, :mday, :hour, :min, :sec, :isdst, :to_i) zone_obj = Object.new def zone_obj.utc_to_local(t) TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i) # <=== adjust hours (`hours + 2`) to match "Europe/Kiev" timezone (that's UTC+2) end ``` Unfortunately it produces incorrect result: ```ruby puts Time.now(in: zone_obj) # 2024-12-13 18:28:53 +0000 <====== wrong UTC offset puts zone_obj.utc_to_local(time) # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734107333> puts zone_obj.utc_to_local(time).to_i # 1734107333 <===== the same Unix timestamp ``` So now result time object has wrong utc offset - `+0000` instead of `+0200`. Okey, so probably Unix timestamp should be adjusted as well. Let's check: ```ruby def zone_obj.utc_to_local(t) TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i + 2 * 60 * 60) # <===== adjust #to_i as well so it returns timestamp + 2 hours end puts Time.now(in: zone_obj) # 2024-12-13 18:28:53 +0200 <======= correct UTC offset puts zone_obj.utc_to_local(time) # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734114533> puts zone_obj.utc_to_local(time).to_i # 1734114533 <====== different Unix timestamp ``` Now we have correct UTC offset `+0200` despite `zone_obj.utc_to_local(time).to_i` returns not original offset but an adjusted one. I assume the difference is caused by a special treatment of time-like object inherited from the Time class. So its `utc_offset` property is used only. But for all the other classes the `#to_i` is used instead. ```ruby zone.utc_to_local(time).class.ancestors # => [TZInfo::TimeWithOffset, TZInfo::WithOffset, Time, Comparable, Object, PP::ObjectMixin, Kernel, BasicObject] ``` This difference is confusing so I think it makes sense either to document it (I mean to document that `#to_i` should return adjusted value for non-related to Time classes) in case it's intentional or to change behaviour for non-related to Time classes and rely not on `#to_i` to calculate UTC offset but on difference in `sec`/`min`/`hours` values otherwise. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:121293] [Ruby master Bug#21181] LoadError in P4Ruby on Windows (MSYS2) After Ruby Security Update
by hjain (Himanshu Jain) 12 Mar '25

12 Mar '25

Issue #21181 has been reported by hjain (Himanshu Jain). ---------------------------------------- Bug #21181: LoadError in P4Ruby on Windows (MSYS2) After Ruby Security Update https://bugs.ruby-lang.org/issues/21181 * Author: hjain (Himanshu Jain) * Status: Open * ruby -v: 3.0.7, 3.1.5, 3.2.4, 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## After updating to Ruby versions 3.0.7, 3.1.5, 3.2.4, and 3.3.1, P4Ruby fails to load with the following error: ***<internal:c:/Ruby/x64/ruby-3.0.7-devkit/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require': 126: The specified module could not be found. - C:/build/p4ruby/lib/P4.so (LoadError)** *** This issue started occurring after the release of CVE-2024-27282: Arbitrary memory address read vulnerability with Regex search. The same P4Ruby build worked on earlier Ruby versions but now consistently fails. Environment: * OS: Windows 10/11 * Ruby Versions Affected: 3.0.7, 3.1.5, 3.2.4, 3.3.1 * MSYS2 Version: mingw-w64-x86_64 toolchain * Perforce P4Ruby Version: Latest from source * Compiler Used: x86_64-w64-mingw32-gcc (from MSYS2) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121299] [Ruby master Feature#21182] Add Hash#rename
by calebm (Caleb Meyer) 12 Mar '25

12 Mar '25

Issue #21182 has been reported by calebm (Caleb Meyer). ---------------------------------------- Feature #21182: Add Hash#rename https://bugs.ruby-lang.org/issues/21182 * Author: calebm (Caleb Meyer) * Status: Open ---------------------------------------- Abstract: Implement Hash#rename which takes as arguments a from key and a to key and renames the from key to the new name. Background: One of the most common data transformations for a hash (in my experience) is renaming a single key. You can do this with the existing hash methods (e.g. `hash['new'] = hash.delete('old')` or `hash.transform_keys('old' => 'new')`) but they feel a bit clunky. Proposal: Add a new method to Hash, something like this: ```ruby class Hash # usage { old: 'value' }.rename(:old, to: :new) # => { new: 'value' } def rename(from, to:) transform_keys(from => to) end def rename!(from, to:) transform_keys!(from => to) end end ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121093] [Ruby master Bug#21146] VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report
by luke-gru (Luke Gruber) 11 Mar '25

11 Mar '25

Issue #21146 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21146: VM_ASSERT(expr) gives bad bug report results when another ractor fails an assertion during printing of report https://bugs.ruby-lang.org/issues/21146 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- test.rb: ```ruby rs = 100.times.map do Ractor.new do cnt = rand 3 cnt += 1 if cnt.zero? sleep cnt 100.times do |i| if i != 0 && i % 50 == 0 Ractor.fail_assert end end end end ``` ractor.rb: ```ruby def self.fail_assert __builtin_cexpr! %q{ VM_ASSERT(0), Qfalse } end ``` > make run I would like to be able to see the bug report for the first failed assertion, without any output from the other ractors. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:121276] [Ruby master Bug#21177] Sometimes Ruby can create and delete long paths, but cannot traverse them
by deivid 11 Mar '25

11 Mar '25

Issue #21177 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #21177: Sometimes Ruby can create and delete long paths, but cannot traverse them https://bugs.ruby-lang.org/issues/21177 * Author: deivid (David Rodríguez) * Status: Open * ruby -v: 3.4.2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the GitHub Actions environment provided by `ruby/setup-ruby` with `os: windows-2022`, one can create directories with long names with no issues. Similarly, one can create files inside these directories, and delete these files and directories explicitly without issues. However, one cannot traverse these directories (`Dir.children`), and as a result, one cannot delete these directories recursively. This is a small script to reproduce the problem: ```ruby require "fileutils" longest_possible_component = "b" * 255 # Can create directories with long names FileUtils.mkdir_p "D:/a/#{longest_possible_component}" puts "FileUtils.mkdir_p ok" # Can create files inside them FileUtils.touch "D:/a/#{longest_possible_component}/c" puts "FileUtils.touch ok" # Can delete files inside them File.delete "D:/a/#{longest_possible_component}/c" puts "File.delete ok" # Can delete them Dir.rmdir "D:/a/#{longest_possible_component}" puts 'Dir.rmdir ok' FileUtils.mkdir_p "D:/a/#{longest_possible_component}" FileUtils.touch "D:/a/#{longest_possible_component}/c" Dir.children "D:/a/#{longest_possible_component}" # FileUtils.rm_r "D:/a" raises too ``` It fails with the following output: ``` $ ruby windows-bug.rb <internal:dir>:184:in 'Dir.open': Filename too long @ dir_initialize - D:/a/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (Errno::ENAMETOOLONG) from windows-bug.rb:24:in 'Dir.children' from windows-bug.rb:24:in '<main>' FileUtils.mkdir_p ok FileUtils.touch ok File.delete ok Dir.rmdir ok ``` Note that `FileUtils.rm_rf` does not raise here because it swallows errors (see https://bugs.ruby-lang.org/issues/18784) but fails to remove the directory too due to this bug. Looking at sources, I wonder if the explicit raise of `ENAMETOOLONG` should be removed from here: https://github.com/ruby/ruby/blob/e418ba0928ab96ac645ab42d77af34806d74c20e/…, and let the system calls themselves raise it if really necessary? -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121118] [Ruby master Feature#21148] Class proposal: IndefiniteNumeric < Numeric
by Student (Nathan Zook) 11 Mar '25

11 Mar '25

Issue #21148 has been reported by Student (Nathan Zook). ---------------------------------------- Feature #21148: Class proposal: IndefiniteNumeric < Numeric https://bugs.ruby-lang.org/issues/21148 * Author: Student (Nathan Zook) * Status: Open ---------------------------------------- Suppose someone deals five cards face down from a regulation poker deck, and we wish to reason about the number of aces. We know that that number is one of zero, one, two, three, or four. Therefore, if someone asks "is this number larger than negative one?", the answer is yes even without ever needing to resolve the actual value. This proposal is inspired by the proposed `Enumerable::Lazy::Length` class of Kevin Newton in response to #21135 The `IndefiniteNumeric` class would serve as a base class for such values. In particular, it relies on a subclass to define `#value`, which returns a definite `Numeric`. ```ruby class IndefiniteNumeric < Numeric def coerce(other) = value.coerce(other) def +(other) = value + other def -(other) = value - other def *(other) = value * other def /(other) = value / other def <=>(other) = value <=> other end ``` It is expected that in particular, `<=>` will be overridden for subclasses where `#value` might be slow to return. Usually, we will know more than just that the value in question is `Numeric`. It seems appropriate have `IndefiniteInteger` and so forth. What is not clear to me is if `IndefiniteInteger` should be a subclass of `IndefiniteNumeric` or of `Integer`. (Such a thing does not appear to be currently possible.) If subclassing cannot be, what about defining `#kind_of?(Integer)` to be `true`? Note: with the length of an `Enumerable` as inspiration, I would argue that an `IndefiniteInteger` might actually value to `Float::INFINITY`, so it should NOT define `<=>` against plus or minus `Float::INFINITY`. -- https://bugs.ruby-lang.org/

3 3