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

[ruby-core:122149] [Ruby Bug#21345] crash on evaluating 'a=>a,*,'
by masterleep2 (Bill Lipa) 19 May '25

19 May '25

Issue #21345 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #21345: crash on evaluating 'a=>a,*,' https://bugs.ruby-lang.org/issues/21345 * Author: masterleep2 (Bill Lipa) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby -e 'a=>a,*,' -e: [BUG] Unexpected node type in pattern matching expression: PM_IMPLICIT_REST_NODE ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +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:0001 p:0000 s:0003 E:0001f0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /opt/local/lib/libruby.3.4.dylib(rb_vm_bugreport+0xb6c) [0x104cbcfdc] /opt/local/lib/libruby.3.4.dylib(rb_bug_without_die_internal+0xfc) [0x104afa12c] /opt/local/lib/libruby.3.4.dylib(rb_bug+0x1c) [0x104e07970] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern.cold.2+0x0) [0x104e0750c] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern+0x42a8) [0x104abd78c] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern+0x3f90) [0x104abd474] /opt/local/lib/libruby.3.4.dylib(pm_compile_match_required_node+0x3b4) [0x104abdb54] /opt/local/lib/libruby.3.4.dylib(pm_compile_node+0x1670) [0x104a8659c] /opt/local/lib/libruby.3.4.dylib(pm_compile_scope_node+0x1c34) [0x104ac2018] /opt/local/lib/libruby.3.4.dylib(pm_iseq_compile_node+0x84) [0x104a84e60] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_with_opt_try+0x1c) [0x104b5cbc8] /opt/local/lib/libruby.3.4.dylib(rb_protect+0xbc) [0x104b060cc] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_with_opt+0x14c) [0x104b5c034] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_main+0xc4) [0x104b5c23c] /opt/local/lib/libruby.3.4.dylib(ruby_process_options+0x16a4) [0x104c12a30] /opt/local/lib/libruby.3.4.dylib(ruby_options+0xb0) [0x104b04b04] /opt/local/bin/ruby3.4(main+0x64) [0x1041eff20] ``` ---Files-------------------------------- crash.txt (14.1 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115995] [Ruby master Bug#20112] Ractors not working properly in ruby 3.3.0
by ariasdiniz (Aria Diniz) 19 May '25

19 May '25

Issue #20112 has been reported by ariasdiniz (Aria Diniz). ---------------------------------------- Bug #20112: Ractors not working properly in ruby 3.3.0 https://bugs.ruby-lang.org/issues/20112 * Author: ariasdiniz (Aria Diniz) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I recently installed Ruby 3.3.0, and noticed that some of my scripts that use Ractors started to struggle with performance. After doing some benchmarks, I noticed that, while Ractors seem to be working well on Ruby 3.2.2, they're not working properly on 3.3.0. I'm using Ubuntu 22.04.3 LTS Here is the benchmark code: ``` ruby # frozen_string_literal: true require 'benchmark' Ractor.new { :warmup } if defined?(Ractor) Benchmark.bmbm do |x| x.report("Thread: ") do threads = [] 8.times do |i| threads << Thread.new do 20000000.times do |j| ((i * 20000000) + j)**2 end end end threads.each(&:join) end x.report("Ractor: ") do ractors = [] 0..8.times do |i| ractors << Ractor.new(i) do |k| 20000000.times do |j| ((k * 20000000) + j)**2 end end end ractors.map(&:take) end end ``` Here is the results for Ruby 3.2.2: Rehearsal -------------------------------------------- Thread: 7.666909 0.001091 7.668000 ( 7.675266) Ractor: 19.318528 0.012017 19.330545 ( 2.505888) ---------------------------------- total: 26.998545sec user system total real Thread: 7.918141 0.004011 7.922152 ( 7.928772) Ractor: 19.366414 0.003954 19.370368 ( 2.517993) Here is the results for Ruby 3.3.0: Rehearsal -------------------------------------------- Thread: 8.634152 0.010895 8.645047 ( 8.645104) Ractor: 100.172179 0.035985 100.208164 ( 15.213245) --------------------------------- total: 108.853211sec user system total real Thread: 9.451236 0.004002 9.455238 ( 9.460132) Ractor: 118.463294 0.119942 118.583236 ( 18.462157) -- https://bugs.ruby-lang.org/

5 4

[ruby-core:122091] [Ruby Bug#21338] TracePoint Not Triggered for Kernel#block_given?
by cfis (Charlie Savage) 19 May '25

19 May '25

Issue #21338 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21338: TracePoint Not Triggered for Kernel#block_given? https://bugs.ruby-lang.org/issues/21338 * Author: cfis (Charlie Savage) * 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 ---------------------------------------- When updating ruby-prof for Ruby 3.4, various tests now fail because a method enter/leave tracepoint is not triggered for `Kernel#block_given?` For example: https://github.com/ruby-prof/ruby-prof/blob/master/test/line_number_test.rb… In 3.3 a tracepoint was triggered but not in earlier Ruby versions. -- https://bugs.ruby-lang.org/

3 5

[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