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

[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:122132] [Ruby Bug#21343] Namespace: singleton classes of root namespace leak between namespaces
by jhawthorn (John Hawthorn) 16 May '25

16 May '25

Issue #21343 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21343: Namespace: singleton classes of root namespace leak between namespaces https://bugs.ruby-lang.org/issues/21343 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby classes all have singleton classes, those singleton classes have singleton classes, and so on with infinite nesting. Since we don't have infinite resources, we create these lazily. Because of this, only a certain number of singleton classes exist in the root namespace. At a certain depth, mutable singleton classes end up shared between namespaces. ``` ruby File.write("/tmp/ntest.rb", <<~'RUBY') p String.singleton_class.singleton_class::Foo String.singleton_class.singleton_class::Bar = 456 RUBY String.singleton_class.singleton_class::Foo = 123 ns = Namespace.new ns.require("/tmp/ntest.rb") p String.singleton_class.singleton_class::Bar ``` ``` RUBY_NAMESPACE=1 ruby nstest2.rb ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. 123 456 ``` -- https://bugs.ruby-lang.org/

2 1

[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

[ruby-core:120671] [Ruby master Bug#21037] Ractors hang with multiple threads
by tenderlovemaking (Aaron Patterson) 14 May '25

14 May '25

Issue #21037 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21037: Ractors hang with multiple threads https://bugs.ruby-lang.org/issues/21037 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-14T20:59:39Z master f1e32914eb) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program hangs, but I don't expect it to hang: ```ruby # frozen_string_literal: true class Map def initialize @r = Ractor.new { cache = { "int" => "integer", "bool" => "boolean" } loop do key = receive Ractor.yield key end } freeze end def fetch(key) @r.send key m = @r.take raise unless key == m m end end tm = Map.new t1 = Thread.new { 10.times { |i| p [i + 1,tm.fetch("int")] } } t2 = Thread.new { 10.times { |i| p [i + 1, tm.fetch("bool")] } } t1.join t2.join ``` I'm not sure why this program hangs yet, but it does both on macOS and Linux. I've tested with master, Ruby 3.4, and Ruby 3.3. I'm not sure why it's hanging yet, but I wanted to file an issue. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:122106] [Ruby Bug#17624] Ractor.receive is not thread-safe
by tenderlovemaking (Aaron Patterson) 14 May '25

14 May '25

Issue #17624 has been updated by tenderlovemaking (Aaron Patterson). Status changed from Assigned to Closed Fixed in 1d4822a ---------------------------------------- Bug #17624: Ractor.receive is not thread-safe https://bugs.ruby-lang.org/issues/17624#change-113259 * Author: dazuma (Daniel Azuma) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- It does not seem to be possible to have multiple blocked `Ractor.receive` calls concurrently in the same Ractor (but different threads). One may succeed but the others will hang indefinitely, even if messages are present in the queue. Example code below. It does the following: 1. Starts a Ractor `r1` that spawns two "listener threads". Each thread calls `Ractor.receive`, which blocks waiting for messages. 2. The main Ractor pauses briefly to ensure that the threads have started, and then sends two messages to the Ractor `r1`, with the expectation that each thread will receive one of them. 3. What actually happens is, the `Ractor.receive` call in *one* of the threads will pick a message and return. However, the `Ractor.receive` call in the other thread remains blocked, even though the second message is in the queue. 4. Ractor `r1`, after a pause to ensure that both messages have been sent, issues another `Ractor.receive` call. This call does not block (because the second message is in the queue), and successfully returns the message. Meanwhile, the second thread's `Ractor.receive` call remains blocked. This demonstrates that the second message has been sent successfully and is receivable, even though the second thread still hasn't returned it. It appears that the second thread's receive call is in a bad state. ``` r1 = Ractor.new do # Start two listener threads t1 = Thread.new do puts "T1 received #{Ractor.receive}" end t2 = Thread.new do puts "T2 received #{Ractor.receive}" end # Pause to ensure that both messages have been sent. # (One of the messages will have been picked up by a # thread, but the other remains in the queue.) sleep(3) # Receive the second message. This will succeed, even # though the second thread is still blocked. puts "Later received #{Ractor.receive}" # Wait for the threads to finish. # This will never complete because one of the threads will not # receive the second message, and is still blocking. [t1, t2].each(&:join) :ok end # Make sure both receive calls are blocking sleep(1) # Send two messages. r1.send(1) r1.send(2) # This never returns because the ractor never completes. puts r1.take ``` This happens both in 3.0.0 release and on 3.1.0 head. ``` % ruby -v ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] ``` ``` % ruby -v ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20] ``` Notes: * This also happens when using `receive_if`. * I would expect this use case to be common when writing a Ractor that contains multiple thread-safe "workers". (This was in fact the use case I was trying to implement when I encountered this issue.) Thus, if we decide this is working as intended, we should document it, and possibly suggest to users that they write their Ractor to funnel communication through a single dedicated thread. -- https://bugs.ruby-lang.org/

1 0