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

[ruby-core:122176] [Ruby Bug#21349] default gems should have version >= 1
by masterleep2 (Bill Lipa) 19 May '25

19 May '25

Issue #21349 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #21349: default gems should have version >= 1 https://bugs.ruby-lang.org/issues/21349 * Author: masterleep2 (Bill Lipa) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Many of the default gems have version numbers less than 1, including venerable offerings such as net-http and yaml. Versions starting with 0 often imply a prereleased or beta status. Surely if a gem has been released as part of the base distribution of ruby itself for a number of years, it is at least worthy of a 1.0 version number. This would reduce uncertainty or confusion about the quality / production readiness of gems distributed with ruby. From ruby 3.4.4: benchmark (default: 0.4.0) cgi (default: 0.4.2) delegate (default: 0.4.0) english (default: 0.8.0) error_highlight (default: 0.7.0) find (default: 0.2.0) io-console (default: 0.8.0) io-nonblock (default: 0.3.1) io-wait (default: 0.3.1) net-http (default: 0.6.0) net-protocol (default: 0.2.2) open-uri (default: 0.5.0) open3 (default: 0.2.1) optparse (default: 0.6.0) ostruct (default: 0.6.1) pathname (default: 0.4.0) pp (default: 0.6.2) prettyprint (default: 0.2.0) pstore (default: 0.1.4) readline (default: 0.0.4) reline (default: 0.6.0) resolv (default: 0.6.0) ruby2_keywords (default: 0.0.5) securerandom (default: 0.4.1) shellwords (default: 0.2.2) singleton (default: 0.3.0) tempfile (default: 0.3.1) time (default: 0.4.1) timeout (default: 0.4.3) tmpdir (default: 0.3.1) tsort (default: 0.2.0) un (default: 0.3.0) weakref (default: 0.1.3) yaml (default: 0.4.0) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121597] [Ruby Bug#21257] YJIT can generate infinite loop when OOM
by rianmcguire (Rian McGuire) 18 May '25

18 May '25

Issue #21257 has been reported by rianmcguire (Rian McGuire). ---------------------------------------- Bug #21257: YJIT can generate infinite loop when OOM https://bugs.ruby-lang.org/issues/21257 * Author: rianmcguire (Rian McGuire) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We've found an edge case where YJIT can generate an infinite loop (jump to the same address) when it's out-of-memory. Reproduction: ```ruby def first second end def second ::File end # Make `second` side exit on its first instruction trace = TracePoint.new(:line) { } trace.enable(target: method(:second)) 32.times do |i| puts i first if i == 29 # We've JITed the methods now - trigger the bug # Trigger a constant cache miss in rb_vm_opt_getconstant_path (in `second`) next time it's called module InvalidateConstantCache File = nil end # nb. this only works in yjit dev mode RubyVM::YJIT.simulate_oom! end end ``` This hangs indefinitely when run with YJIT (`./configure --enable-yjit=dev` is required for simulate_oom). If we attach a debugger to the Ruby process at this point, it's stuck in an infinite loop: ``` $ lldb -p 9753 (lldb) process attach --pid 9753 Process 9753 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x0000000104b202b8 -> 0x104b202b8: b 0x104b202b8 0x104b202bc: nop 0x104b202c0: nop 0x104b202c4: nop Target 0: (ruby) stopped. Executable module set to "/Users/rian/opt/ruby/bin/ruby". Architecture set to: arm64-apple-macosx-. ``` We've reproduced this on: ``` ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin23] ruby 3.5.0dev (2025-04-08T06:46:45Z master b68fe530f1) +PRISM [arm64-darwin23] ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122136] [Ruby Bug#21344] Segment Fault Caused by no Backported Patches
by tianstcht (Haotian Cheng) 18 May '25

18 May '25

Issue #21344 has been reported by tianstcht (Haotian Cheng). ---------------------------------------- Bug #21344: Segment Fault Caused by no Backported Patches https://bugs.ruby-lang.org/issues/21344 * Author: tianstcht (Haotian Cheng) * Status: Open * ruby -v: 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In my local machine(3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu]), which is the default version in ubuntu2404, a segmentation fault can be stably triggered by the poc including malicious xml data. The poc here: ```ruby require "rexml/document" puts REXML::VERSION def poc1(size) input = <<EOF <mydoc> <tt>#{'&' + '1'*size + '#x2F3F' + ' '}</tt> </mydoc> EOF parser = REXML::Document.new input end poc1(8_999_999) ``` The issue has been fixed in this commit: https://github.com/ruby/ruby/commit/b959263b58e26ef630c085f9f7ddc04373a998c7 But the fix haven't been backported to Ruby 3.2 and 3.3. Based on the developer's response, I think the backporting may be needed so the issue built. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121782] [Ruby Bug#21297] Update net-imap for ruby 3.2, 3.3, 3.4
by nevans (Nicholas Evans) 18 May '25

18 May '25

Issue #21297 has been reported by nevans (Nicholas Evans). ---------------------------------------- Bug #21297: Update net-imap for ruby 3.2, 3.3, 3.4 https://bugs.ruby-lang.org/issues/21297 * Author: nevans (Nicholas Evans) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The bundled `net-imap` versions are vulnerable to CVE-2025-43857 (GHSA-j3g3-5qv5-52mj). This vulnerability does not affect securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). Fixing the issue requires upgrading to [v0.2.5], [v0.3.9], [v0.4.20], or [v0.5.7]. * ruby 3.2.8 bundles net-imap v0.3.8 PR: Bump net-imap to 0.3.9 for Ruby 3.2 https://github.com/ruby/ruby/pull/13213 * ruby 3.3.8 bundles net-imap v0.4.19 PR: Bump net-imap to 0.4.21 for Ruby 3.3 https://github.com/ruby/ruby/pull/13214 * ruby 3.4.3 bundles net-imap v0.5.6 PR: Bump net-imap to v0.5.8 for Ruby 3.4 https://github.com/ruby/ruby/pull/13215 I didn't have a release ready in time to be bundled with the final version of ruby 3.1, so I haven't created a PR for [v0.2.5]. The workaround is to uninstall the vulnerable bundled versions and `gem install net-imap`. Security Advisory Links: * https://www.cve.org/CVERecord?id=CVE-2025-43857 * https://github.com/ruby/net-imap/security/advisories/GHSA-j3g3-5qv5-52mj [v0.2.5]: https://github.com/ruby/net-imap/releases/tag/v0.2.5 [v0.3.9]: https://github.com/ruby/net-imap/releases/tag/v0.3.9 [v0.4.20]: https://github.com/ruby/net-imap/releases/tag/v0.4.20 [v0.5.7]: https://github.com/ruby/net-imap/releases/tag/v0.5.7 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122052] [Ruby Bug#21331] heap-use-after-free caused by rehash during transform_values!
by cyruscyliu (Qiang Liu) 17 May '25

17 May '25

Issue #21331 has been reported by cyruscyliu (Qiang Liu). ---------------------------------------- Bug #21331: heap-use-after-free caused by rehash during transform_values! https://bugs.ruby-lang.org/issues/21331 * 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 transform_values!. ``` $a = (1..1337).to_h { |k| [k, k] } $a.transform_values! { |v| $a.rehash v * 2 } ``` ``` $ 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_transform_values.rb `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. ================================================================= ==225007==ERROR: AddressSanitizer: heap-use-after-free on address 0x52f00000e408 at pc 0x64e677315414 bp 0x7fff926378f0 sp 0x7fff926378e8 WRITE of size 8 at 0x52f00000e408 thread T0 #0 0x64e677315413 in st_general_foreach /media/test/ruby/build/../st.c:1560:33 #1 0x64e677133dce in rb_hash_stlike_foreach_with_replace /media/test/ruby/build/../hash.c:1425:16 #2 0x64e677133dce in rb_hash_transform_values_bang /media/test/ruby/build/../hash.c:3552:9 #3 0x64e67745a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #4 0x64e67744304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #5 0x64e677442b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #6 0x64e67740a539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #7 0x64e67740a539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #8 0x64e6773ffcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #9 0x64e6770bbbf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #10 0x64e6770bbbf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #11 0x64e6770b72b0 in rb_main /media/test/ruby/build/../main.c:42:12 #12 0x64e6770b72b0 in main /media/test/ruby/build/../main.c:62:12 #13 0x7c2903e2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #14 0x7c2903e2a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #15 0x64e676fddd94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) 0x52f00000e408 is located 8 bytes inside of 49152-byte region [0x52f00000e400,0x52f00001a400) freed by thread T0 here: #0 0x64e67707894a in free (/media/test/ruby/build/ruby+0x1e694a) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) #1 0x64e6770e344b in rb_gc_impl_free /media/test/ruby/build/../gc/default/default.c:8099:9 #2 0x64e6770e344b in ruby_sized_xfree /media/test/ruby/build/../gc.c:5225:13 #3 0x64e6770e344b in ruby_xfree /media/test/ruby/build/../gc.c:5236:5 #4 0x64e67712be09 in hash_st_free /media/test/ruby/build/../hash.c:1218:5 #5 0x64e67712be09 in rb_hash_rehash /media/test/ruby/build/../hash.c:2026:9 #6 0x64e67745a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #7 0x64e67744304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #8 0x64e677442b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #9 0x64e6774076f3 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #10 0x64e6774076f3 in vm_exec_core /media/test/ruby/build/../insns.def:899:11 #11 0x64e6773ffcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #12 0x64e677475dcc in invoke_iseq_block_from_c /media/test/ruby/build/../vm.c:1653:12 #13 0x64e677475dcc in invoke_block_from_c_bh /media/test/ruby/build/../vm.c:1667:20 #14 0x64e677427cca in vm_yield_with_cref /media/test/ruby/build/../vm.c:1704:12 #15 0x64e677427cca in vm_yield /media/test/ruby/build/../vm.c:1712:12 #16 0x64e677427cca in rb_yield_0 /media/test/ruby/build/../vm_eval.c:1361:12 #17 0x64e677427cca in rb_yield /media/test/ruby/build/../vm_eval.c #18 0x64e67713db0d in transform_values_foreach_replace /media/test/ruby/build/../hash.c:3482:23 #19 0x64e67731443d in st_general_foreach /media/test/ruby/build/../st.c:1559:22 #20 0x64e677133dce in rb_hash_stlike_foreach_with_replace /media/test/ruby/build/../hash.c:1425:16 #21 0x64e677133dce in rb_hash_transform_values_bang /media/test/ruby/build/../hash.c:3552:9 #22 0x64e67745a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #23 0x64e67744304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #24 0x64e677442b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #25 0x64e67740a539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #26 0x64e67740a539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #27 0x64e6773ffcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #28 0x64e6770bbbf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #29 0x64e6770bbbf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #30 0x64e6770b72b0 in rb_main /media/test/ruby/build/../main.c:42:12 #31 0x64e6770b72b0 in main /media/test/ruby/build/../main.c:62:12 #32 0x7c2903e2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #33 0x7c2903e2a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #34 0x64e676fddd94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) previously allocated by thread T0 here: #0 0x64e677078be3 in malloc (/media/test/ruby/build/ruby+0x1e6be3) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) #1 0x64e67711fdf5 in rb_gc_impl_malloc /media/test/ruby/build/../gc/default/default.c:8114:5 #2 0x64e6770ee9f2 in ruby_xmalloc_body /media/test/ruby/build/../gc.c:5116:12 #3 0x64e6770ee9f2 in ruby_xmalloc /media/test/ruby/build/../gc.c:5106:34 #4 0x64e67730e4a1 in rb_st_init_existing_table_with_size /media/test/ruby/build/../st.c:559:39 #5 0x64e6773105b0 in rb_st_init_table_with_size /media/test/ruby/build/../st.c:585:5 #6 0x64e6773105b0 in rebuild_table /media/test/ruby/build/../st.c:753:19 #7 0x64e6773105b0 in rebuild_table_if_necessary /media/test/ruby/build/../st.c:1125:9 #8 0x64e677310f6b in st_add_direct_with_hash /media/test/ruby/build/../st.c:1187:5 #9 0x64e677313cf3 in rb_st_update /media/test/ruby/build/../st.c:1502:13 #10 0x64e67712e018 in rb_hash_stlike_update /media/test/ruby/build/../hash.c:1686:12 #11 0x64e67712e018 in tbl_update /media/test/ruby/build/../hash.c:1727:15 #12 0x64e67712de82 in rb_hash_aset /media/test/ruby/build/../hash.c #13 0x64e67712e510 in rb_hash_set_pair /media/test/ruby/build/../hash.c:3715:5 #14 0x64e6773fbbf3 in vm_yield_with_cfunc /media/test/ruby/build/../vm_insnhelper.c:5161:11 #15 0x64e6774757f9 in invoke_block_from_c_bh /media/test/ruby/build/../vm.c:1672:16 #16 0x64e677427cca in vm_yield_with_cref /media/test/ruby/build/../vm.c:1704:12 #17 0x64e677427cca in vm_yield /media/test/ruby/build/../vm.c:1712:12 #18 0x64e677427cca in rb_yield_0 /media/test/ruby/build/../vm_eval.c:1361:12 #19 0x64e677427cca in rb_yield /media/test/ruby/build/../vm_eval.c #20 0x64e6772511c7 in range_each_fixnum_loop /media/test/ruby/build/../range.c:1059:9 #21 0x64e6772511c7 in range_each /media/test/ruby/build/../range.c:1096:16 #22 0x64e67746dfd5 in vm_call0_cfunc_with_frame /media/test/ruby/build/../vm_eval.c:164:15 #23 0x64e67746dfd5 in vm_call0_cfunc /media/test/ruby/build/../vm_eval.c:178:12 #24 0x64e67746dfd5 in vm_call0_body /media/test/ruby/build/../vm_eval.c:229:15 #25 0x64e677471a0a in vm_call0_cc /media/test/ruby/build/../vm_eval.c:101:12 #26 0x64e677471a0a in rb_call0 /media/test/ruby/build/../vm_eval.c:571:12 #27 0x64e6774295f5 in rb_call /media/test/ruby/build/../vm_eval.c:890:12 #28 0x64e6774295f5 in iterate_method /media/test/ruby/build/../vm_eval.c:1545:12 #29 0x64e677429bf5 in rb_iterate0 /media/test/ruby/build/../vm_eval.c:1487:18 #30 0x64e677429287 in rb_iterate_internal /media/test/ruby/build/../vm_eval.c:1519:12 #31 0x64e677429287 in rb_block_call_kw /media/test/ruby/build/../vm_eval.c:1568:12 #32 0x64e677429287 in rb_block_call /media/test/ruby/build/../vm_eval.c:1554:12 #33 0x64e6776c75e0 in enum_hashify_into /media/test/ruby/build/../enum.c:743:5 #34 0x64e6776c75e0 in enum_hashify /media/test/ruby/build/../enum.c:750:12 #35 0x64e6776c75e0 in enum_to_h /media/test/ruby/build/../enum.c:791:12 #36 0x64e67745a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #37 0x64e67744304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #38 0x64e677442b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #39 0x64e67740a539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #40 0x64e67740a539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #41 0x64e6773ffcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #42 0x64e6770bbbf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #43 0x64e6770bbbf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #44 0x64e6770b72b0 in rb_main /media/test/ruby/build/../main.c:42:12 #45 0x64e6770b72b0 in main /media/test/ruby/build/../main.c:62:12 #46 0x7c2903e2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #47 0x7c2903e2a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #48 0x64e676fddd94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) SUMMARY: AddressSanitizer: heap-use-after-free /media/test/ruby/build/../st.c:1560:33 in st_general_foreach 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 ==225007==ABORTING triaged/hash_transform_values.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:0010 e:000009 CFUNC :transform_values! c:0002 p:0016 s:0006 e:000005 EVAL triaged/hash_transform_values.rb:3 [FINISH] c:0001 p:0000 s:0003 E:000be0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- triaged/hash_transform_values.rb:3:in '<main>' triaged/hash_transform_values.rb:3:in 'transform_values!' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ./ruby(___interceptor_backtrace) [0x64e6770226aa] /media/test/ruby/build/ruby(rb_print_backtrace+0x14) [0x64e677795c97] /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) [0x64e6776ea16c] /media/test/ruby/build/../error.c:1097 /media/test/ruby/build/ruby(rb_bug_without_die+0x127) [0x64e6776e9e87] /media/test/ruby/build/../error.c:1106 ./ruby(0x64e67709d2aa) [0x64e67709d2aa] ./ruby(0x64e67707da2f) [0x64e67707da2f] ./ruby(0x64e677080ab5) [0x64e677080ab5] ./ruby(__asan_report_store8) [0x64e677081bdf] /media/test/ruby/build/ruby(st_general_foreach+0x12e4) [0x64e677315414] /media/test/ruby/build/../st.c:1560 /media/test/ruby/build/ruby(rb_hash_stlike_foreach_with_replace+0x16) [0x64e677133dcf] /media/test/ruby/build/../hash.c:1425 /media/test/ruby/build/ruby(rb_hash_transform_values_bang) /media/test/ruby/build/../hash.c:3552 /media/test/ruby/build/ruby(vm_cfp_consistent_p+0x0) [0x64e67745a9dc] ../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) [0x64e67744304b] ../vm_insnhelper.c:4776 ./ruby(vm_call_method+0x2d4) [0x64e677442b14] /media/test/ruby/build/ruby(vm_sendish+0x11f) [0x64e67740a53a] ../vm_insnhelper.c:5995 /media/test/ruby/build/ruby(vm_exec_core) ../insns.def:851 ./ruby(vm_exec_loop+0x0) [0x64e6773ffcd8] /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) [0x64e6770bbbf1] /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) [0x64e6770b72b1] /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) [0x7c2903e2a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x7c2903e2a28b] ../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) [0x64e676fddd95] -- Other runtime information ----------------------------------------------- * Loaded script: triaged/hash_transform_values.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/

5 4

[ruby-core:121556] [Ruby Bug#21220] Memory corruption in update_line_coverage() [write at index -1]
by mbcodeandsound (Mike Bourgeous) 17 May '25

17 May '25

Issue #21220 has been reported by mbcodeandsound (Mike Bourgeous). ---------------------------------------- Bug #21220: Memory corruption in update_line_coverage() [write at index -1] https://bugs.ruby-lang.org/issues/21220 * Author: mbcodeandsound (Mike Bourgeous) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello! I have encountered repeatable memory corruption in Ruby 3.4.2 on Ubuntu 24.04.2 LTS, which I believe is happening in update_line_coverage(). I could not reproduce this on Ruby 3.x or earlier. My findings follow. I also have detailed step-by-step notes at https://github.com/mike-bourgeous/mb-sound/issues/36 ### Summary `update_line_coverage()` calls `rb_sourceline()`, subtracts one from its return value, and uses this as an index into an Array. Sometimes `rb_sourceline()` returns 0, and when this happens, `update_line_coverage()` will write to index -1 of the array. This corrupts the heap before the Array, resulting in a program crash later during GC. As I am new to the Ruby codebase I do not know if it's normal for rb_sourceline() to return 0 and update_line_coverage() should handle it, or if something is wrong in the code that ultimately feeds rb_sourceline(). ### Symptom On Linux, affected processes print one of the following errors and exit: ``` munmap_chunk(): invalid pointer Aborted (core dumped) ``` or, if preloading libc_malloc_debug.so ``` malloc_check_get_size: memory corruption Aborted (core dumped) ``` ### Reproduction I have a reduced GitHub project that can reproduce the bug consistently both on my machine and in CI. When I try to reduce the size of this repo further, the bug stops happening. The issue only reproduces locally if the `coverage/` directory has a large `.resultset.json`. - **Repo:** https://github.com/mike-bourgeous/reproduce-simplecov-ruby34-bug - **Example of the bug:** https://github.com/mike-bourgeous/reproduce-simplecov-ruby34-bug/actions/ru… ``` shell # Repeatedly running the process increases the likelihood of crashing # as the SimpleCov result file grows. for f in `seq 1 100`; do echo $f; ruby -r./spec/simplecov_helper.rb bin/midi_roll.rb -c 40 -r 2 spec/test_data/all_notes.mid > /dev/null || break ; done ``` ### Research and reasoning I initially found the crash during a live stream when I was upgrading a project from Ruby 2.7 to Ruby 3.4. The crash occurred when an RSpec test tried to spawn another Ruby process, while using SimpleCov to measure code coverage in both. I discovered a workaround of disabling SimpleCov in the nested process when running tests on Ruby 3.4. I used a somewhat unusual approach to get coverage metrics for subprocesses. After the stream I wanted to understand what was really happening and see if I could find a way to re-enable test code coverage for subprocesses. I used a combination of Valgrind, GDB, and trial and error to narrow down the site of the crash and the original corruption. I wrote [a GDB script to automate information gathering](https://github.com/mike-bourgeous/reproduce-simplecov-ruby34-bug… when the GC crash occurred, and Valgrind+vgdb to identify the original write that appeared to cause the corruption. I reviewed the Git history of update_line_coverage(), rb_sourceline() (and the functions it calls), and a few other functions, but did not find any obvious changes between Ruby 3.3.x and Ruby 3.4.x, so the root cause is somewhere beyond my familiarity with the codebase. Full details of my process are in my issue notes: https://github.com/mike-bourgeous/mb-sound/issues/36 ---Files-------------------------------- corruption_c_stack.txt (2.63 KB) corruption_ruby_stack.txt (948 Bytes) crash_ruby_stack.txt (4.46 KB) crash_c_stack.txt (26.2 KB) -- https://bugs.ruby-lang.org/

5 15

[ruby-core:122156] [Ruby Feature#4539] Array#zip_with
by matheusrich (Matheus Richard) 16 May '25

16 May '25

Issue #4539 has been updated by matheusrich (Matheus Richard). @matz maybe too obvious, but how about `zip_map`? ---------------------------------------- Feature #4539: Array#zip_with https://bugs.ruby-lang.org/issues/4539#change-113305 * Author: citizen428 (Michael Kohl) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Inspired by Haskell's `zipWith` function, I hacked on together for Ruby: ```ruby [1,2,3].zip_with([6,5,4], :+) #=> [7, 7, 7] [1,2,3].zip_with([6,5,4]) { |a,b| 3*a+2*b } #=> [15, 16, 17] ``` So far I only have a Ruby version of it: https://gist.github.com/731702b90757e21cadcb My questions: 1. Would this method be considered a worthwhile addition to `Array`? 2. I've never hacked on the C side of Ruby (read some parts of the source though) and my C is quite rusty. I'd like to change that, would somebody be willing to help me turn this into a proper patch? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121941] [Ruby Bug#21315] Finalizers violate the `rb_ractor_confirm_belonging` assertion
by byroot (Jean Boussier) 15 May '25

15 May '25

Issue #21315 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21315: Finalizers violate the `rb_ractor_confirm_belonging` assertion https://bugs.ruby-lang.org/issues/21315 * Author: byroot (Jean Boussier) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Reproduction (with assertions enabled): ```ruby require "tempfile" Ractor.new do 10.times do Tempfile.new end end.take GC.start ``` ``` <OBJ_INFO:rb_ractor_confirm_belonging@../src/ractor_core.h:375> (File) /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 3.5.0dev (2025-05-09T15:51:24Z pull/13291/merge e289a1dc58) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0007 s:0025 e:000024 METHOD /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387 [FINISH] c:0004 p:0022 s:0020 e:000019 METHOD /home/runner/work/ruby/ruby/src/lib/prism/parse_result.rb:833 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :parse_lex_file c:0002 p:0006 s:0007 e:000006 BLOCK /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26:in 'block in test_parse_lex_file' /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26:in 'parse_lex_file' /home/runner/work/ruby/ruby/src/lib/prism/parse_result.rb:833:in 'initialize' /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387:in 'call' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/runner/work/ruby/ruby/build/ruby(rb_print_backtrace+0x14) [0x561441aeedbf] ../src/vm_dump.c:843 /home/runner/work/ruby/ruby/build/ruby(rb_vm_bugreport) ../src/vm_dump.c:1175 /home/runner/work/ruby/ruby/build/ruby(bug_report_end+0x0) [0x561441aa3f39] ../src/error.c:1097 /home/runner/work/ruby/ruby/build/ruby(rb_bug_without_die_internal) ../src/error.c:1097 /home/runner/work/ruby/ruby/build/ruby(die+0x0) [0x5614416e237f] ../src/error.c:1115 /home/runner/work/ruby/ruby/build/ruby(rb_bug) ../src/error.c:1117 /home/runner/work/ruby/ruby/build/ruby(rb_ractor_confirm_belonging+0xde) [0x56144188c6be] ../src/ractor_core.h:376 /home/runner/work/ruby/ruby/build/ruby(vm_exec_core+0xef) [0x5614418b23ef] /home/runner/work/ruby/ruby/build/vm.inc:2500 /home/runner/work/ruby/ruby/build/ruby(rb_vm_exec+0x156) [0x5614418a4676] ../src/vm.c:2618 /home/runner/work/ruby/ruby/build/ruby(vm_call0_cc+0x13d) [0x5614418aa1dd] ../src/vm_eval.c:101 /home/runner/work/ruby/ruby/build/ruby(rb_vm_call0+0x4c) [0x5614418b1cc5] ../src/vm_eval.c:61 /home/runner/work/ruby/ruby/build/ruby(rb_vm_call_kw) ../src/vm_eval.c:326 /home/runner/work/ruby/ruby/build/ruby(rb_check_funcall_default_kw) ../src/vm_eval.c:694 /home/runner/work/ruby/ruby/build/ruby(rb_gc_run_obj_finalizer+0x1cf) [0x56144170220f] ../src/gc.c:306 /home/runner/work/ruby/ruby/build/ruby(rb_multi_ractor_p+0x0) [0x56144170246f] ../src/gc/default/default.c:2820 /home/runner/work/ruby/ruby/build/ruby(rb_vm_lock_enter) ../src/vm_sync.h:74 /home/runner/work/ruby/ruby/build/ruby(rb_gc_vm_lock) ../src/gc.c:137 /home/runner/work/ruby/ruby/build/ruby(finalize_list) ../src/gc/default/default.c:2843 /home/runner/work/ruby/ruby/build/ruby(finalize_deferred_heap_pages) ../src/gc/default/default.c:2866 ``` I think it wouldn't be hard to disable that check when running a finalizer, but I don't know if it's the correct thing to do. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:122098] [Ruby Bug#21339] Namespace: `RubyVM::InstructionSequence.load_iseq` isn't called for the root namespace
by byroot (Jean Boussier) 15 May '25

15 May '25

Issue #21339 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21339: Namespace: `RubyVM::InstructionSequence.load_iseq` isn't called for the root namespace https://bugs.ruby-lang.org/issues/21339 * Author: byroot (Jean Boussier) * Status: Assigned * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 3.5.0dev (2025-05-14T12:41:46Z master b5575a80bc) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby File.write("/tmp/compile-cache.rb", <<~'RUBY') class << RubyVM::InstructionSequence def load_iseq(path) p [:load_iseq, path] RubyVM::InstructionSequence.compile_file(path) end end RUBY File.write("/tmp/test-file.rb", "") puts "main:" require "/tmp/compile-cache.rb" require "/tmp/test-file.rb" if ENV["RUBY_NAMESPACE"] puts "namespace:" ns = Namespace.new ns.require("/tmp/compile-cache.rb") ns.require("/tmp/test-file.rb") end ``` Expected behavior: I would expect `load_iseq` to be invoked both in the root namespace and the user namespace when `RUBY_NAMESPACE=1`. Actual behavior: Somehow it's only invoked in the user namespace: ```bash main: [:compile_cache_setup] [:load_iseq, "/tmp/test-file.rb"] ``` ```bash main: [:compile_cache_setup] namespace: [:compile_cache_setup] [:load_iseq, "/tmp/test-file.rb"] ``` But I don't understand why. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122109] [Ruby Bug#17420] Unsafe mutation of $" when doing non-RubyGems require in Ractor
by Eregon (Benoit Daloze) 14 May '25

14 May '25

Issue #17420 has been updated by Eregon (Benoit Daloze). Yep, the original ticket was about incorrectly allowing `require` in Ractors and that could segfault. https://github.com/ruby/ruby/pull/11142 is the proper fix. ---------------------------------------- Bug #17420: Unsafe mutation of $" when doing non-RubyGems require in Ractor https://bugs.ruby-lang.org/issues/17420#change-113262 * Author: Eregon (Benoit Daloze) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.0.0dev (2020-12-16T10:12:48Z master a9a7f4d8b8) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- With an empty file `a.rb`: ``` $ ruby --disable-gems -e 'Ractor.new { puts $" }.take' -e:1:in `block in <main>': can not access global variables $" from non-main Ractors (RuntimeError) ``` That is expected, given the rules for global variables. ``` ruby --disable-gems -e 'Ractor.new { require "./a.rb"; }.take; p $"' [... , "/home/eregon/a.rb"] ``` Is it OK that the Ractor can do `require`, which does modify `$"`? I think it's not, and it might lead to segfaults if e.g. the main Ractor mutates `$"` in parallel to some other Ractor doing `require`. Probably `require` needs to be forbidden in non-main Ractors (it does mutate `$"`, so it's logical), or there needs to be always VM-global synchronization on any access to `$"` (otherwise, segfaults are possible). The latter doesn't seem reasonable, especially when considering the user might do `$".each { ... }`. --- Note that RubyGems' `require` does not work on non-main Ractors (pretty much expected given it depends on a lot of global state): ``` $ ruby -e 'Ractor.new { require "./a.rb"; }.take' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.0.0/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. (NameError) ``` This probably also has consequences for `autoload`. Maybe the `zeitwerk` gem can help with the mode to resolve all autoload at once. -- https://bugs.ruby-lang.org/

1 0