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

[ruby-core:122082] [Ruby Bug#21336] "Cannot malloc during GC" on WASM
by k0kubun (Takashi Kokubun) 14 May '25

14 May '25

Issue #21336 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #21336: "Cannot malloc during GC" on WASM https://bugs.ruby-lang.org/issues/21336 * Author: k0kubun (Takashi Kokubun) * Status: Open * Assignee: katei (Yuta Saito) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED ---------------------------------------- The patch for [Bug #21331] https://github.com/ruby/ruby/pull/13317 introduced a new bug for WASM build. ``` basictest/test.rb:array ...........................basictest/test.rb:53: [BUG] Cannot malloc during GC ruby 3.5.0dev (2025-05-13T13:39:06Z pull/13317/merge 5e6d7a06ee) +PRISM [wasm32-wasi] -- Control frame information ----------------------------------------------- c:0005 p:0002 s:0065 e:000064 METHOD basictest/test.rb:53 c:0004 p:0005 s:0061 e:000059 METHOD basictest/test.rb:68 c:0003 p:0068 s:0056 e:000055 METHOD basictest/test.rb:119 c:0002 p:8173 s:0048 E:000a00 EVAL basictest/test.rb:889 [FINISH] c:0001 p:0000 s:0003 E:0005a8 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- basictest/test.rb:889:in '<main>' basictest/test.rb:119:in 'test_ok' basictest/test.rb:68:in 'pass' basictest/test.rb:53:in 'passed_string' ``` https://github.com/ruby/ruby/actions/runs/14998139079/job/42139552597 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122066] [Ruby Bug#21334] Namespaces and object reference sharing
by fxn (Xavier Noria) 14 May '25

14 May '25

Issue #21334 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21334: Namespaces and object reference sharing https://bugs.ruby-lang.org/issues/21334 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- # Implications related to builtin classes and modules As we know, when a namespace is created, builtin classes in the namespace are as in the root one. This applies to all references to them, explicit or implicit. This is at the core of the current implementation and semantics of namespaces. However, the feature also allow object references to cross namespaces. For example, via method calls: ```ruby ns::Foo.m(ref) ``` And this has implications that do not seem good to me. Examples: 1. If `ref` has an HTTP client in an attribute, that depends on a parser gem, which depends on a string utils gem, that adds `blank?` to `String`, that call is broken because the transitive code at some point may perhaps hit a `blank?` call, and the user has no way to tell. 2. If `ref` is a reference created by a gem managed by Zeitwerk (there are hundreds), the call is broken too. When `m` uses `ref`, it might need to lazy load something, and that won't work because the [Kernel#require](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/core… and [Module#const_added](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/… decorations are gone within the namespace. Please, note whether a gem loads with Zeitwerk or not is transparent to the user of the gem, by design. How do gems load their code is a private matter that is not, and should not be, documented. So the user does not know. # Implications related to different gem versions In the example above, `ref` could be an instance of an object that corresponds to v2.0 of a gem, and perhaps the code under the namespace has a transitive dependency on v1.0. Mixing such references seems like a receipt for a good amount of Paracetamol. # Proposal This is all so brittle, that I would like to ask for a fundamental reconsideration of cross-namespace object reference passing. The rules are consistent within a namespace, problem is opening that up to cross-namespace communication. Maybe redefine communication across namespaces in a very restrictive way that make these issues by design. Maybe remove cross-namespace communication in this manner altogether. Or some other option people can think of. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:121754] [Ruby Bug#21289] Fix C level backtraces for USE_ELF
by dodecadaniel (Daniel Colson) 14 May '25

14 May '25

Issue #21289 has been reported by dodecadaniel (Daniel Colson). ---------------------------------------- Bug #21289: Fix C level backtraces for USE_ELF https://bugs.ruby-lang.org/issues/21289 * Author: dodecadaniel (Daniel Colson) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- After upgrading GitHub to Ruby 3.4 we noticed that we stopped getting useful C level backtrace information in our crash reports. We traced it back to https://github.com/github/ruby/commit/7dd2afbe3a14d021e5554288517709f5778c3…. Passing 0 instead of -1 makes sense for the Mach-O version of `fill_lines`, but there is a separate ELF version of `fill_lines` that still has special handling for -1: https://github.com/ruby/ruby/blob/58e3aa02240a9ec1b5fe6ce60d63828c2cf0c73a/…. More details in the corresponding PR: https://github.com/ruby/ruby/pull/13195 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122053] [Ruby Bug#21332] heap-use-after-free caused by mutating the set
by cyruscyliu (Qiang Liu) 13 May '25

13 May '25

Issue #21332 has been reported by cyruscyliu (Qiang Liu). ---------------------------------------- Bug #21332: heap-use-after-free caused by mutating the set https://bugs.ruby-lang.org/issues/21332 * 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 mutating the set. hash() returning 0 is important to create the collision and then trigger eql? ``` $flag = false $c = 0 class C def hash return 0 end def eql?(other) if $flag if $c == 0 $c += 1 $a.merge((1...10).map {C.new}) return false end end end end $a = Set.new((1..10).map { |o| C.new }) $a.delete_if { |x| if $c == 0 $a.delete($a.to_a[0]) end $flag = true } ``` ``` $ 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/set_delete_if.rb `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. ================================================================= ==229421==ERROR: AddressSanitizer: heap-use-after-free on address 0x511000009dd0 at pc 0x632e6e7fc01d bp 0x7fffb8fd7170 sp 0x7fffb8fd7168 READ of size 8 at 0x511000009dd0 thread T0 #0 0x632e6e7fc01c in set_general_foreach /media/test/ruby/build/../st.c:3047:13 #1 0x632e6e8026ff in set_foreach_call /media/test/ruby/build/../set.c:329:11 #2 0x632e6e59e5c6 in rb_ensure /media/test/ruby/build/../eval.c:1074:18 #3 0x632e6e80247c in set_iter /media/test/ruby/build/../set.c:352:9 #4 0x632e6e7ff9f4 in set_i_delete_if /media/test/ruby/build/../set.c:769:5 #5 0x632e6e93a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #6 0x632e6e92304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #7 0x632e6e922b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #8 0x632e6e8ea539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #9 0x632e6e8ea539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #10 0x632e6e8dfcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #11 0x632e6e59bbf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #12 0x632e6e59bbf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #13 0x632e6e5972b0 in rb_main /media/test/ruby/build/../main.c:42:12 #14 0x632e6e5972b0 in main /media/test/ruby/build/../main.c:62:12 #15 0x7a1fdf62a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #16 0x7a1fdf62a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #17 0x632e6e4bdd94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) 0x511000009dd0 is located 16 bytes inside of 256-byte region [0x511000009dc0,0x511000009ec0) freed by thread T0 here: #0 0x632e6e55894a in free (/media/test/ruby/build/ruby+0x1e694a) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) #1 0x632e6e5c344b in rb_gc_impl_free /media/test/ruby/build/../gc/default/default.c:8099:9 #2 0x632e6e5c344b in ruby_sized_xfree /media/test/ruby/build/../gc.c:5225:13 #3 0x632e6e5c344b in ruby_xfree /media/test/ruby/build/../gc.c:5236:5 #4 0x632e6e7f94eb in set_rebuild_move_table /media/test/ruby/build/../st.c:2592:5 #5 0x632e6e7f94eb in set_rebuild_table /media/test/ruby/build/../st.c:2542:9 #6 0x632e6e7f94eb in set_rebuild_table_if_necessary /media/test/ruby/build/../st.c:2876:9 #7 0x632e6e7f94eb in rb_set_insert /media/test/ruby/build/../st.c:2894:5 #8 0x632e6e802b4b in set_table_insert_wb /media/test/ruby/build/../set.c:378:15 #9 0x632e6e802b4b in set_merge_enum_into /media/test/ruby/build/../set.c:1121:13 #10 0x632e6e800a1f in set_i_merge /media/test/ruby/build/../set.c:1147:9 #11 0x632e6e93a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #12 0x632e6e92304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #13 0x632e6e922b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #14 0x632e6e8e76f3 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #15 0x632e6e8e76f3 in vm_exec_core /media/test/ruby/build/../insns.def:899:11 #16 0x632e6e8dfcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #17 0x632e6e94dcad in vm_call0_body /media/test/ruby/build/../vm_eval.c:225:20 #18 0x632e6e905fa6 in vm_call0_cc /media/test/ruby/build/../vm_eval.c:101:12 #19 0x632e6e905fa6 in rb_funcallv_scope /media/test/ruby/build/../vm_eval.c:1064:16 #20 0x632e6e906c53 in rb_funcallv /media/test/ruby/build/../vm_eval.c:1079:12 #21 0x632e6e906c53 in rb_funcall /media/test/ruby/build/../vm_eval.c:1136:12 #22 0x632e6e6d443b in rb_eql /media/test/ruby/build/../object.c:199:18 #23 0x632e6e608cfb in rb_any_cmp /media/test/ruby/build/../hash.c:142:13 #24 0x632e6e7fb7c4 in set_find_entry /media/test/ruby/build/../st.c:2639:9 #25 0x632e6e7fb7c4 in set_general_foreach /media/test/ruby/build/../st.c:3098:23 #26 0x632e6e8026ff in set_foreach_call /media/test/ruby/build/../set.c:329:11 #27 0x632e6e59e5c6 in rb_ensure /media/test/ruby/build/../eval.c:1074:18 #28 0x632e6e80247c in set_iter /media/test/ruby/build/../set.c:352:9 #29 0x632e6e7ff9f4 in set_i_delete_if /media/test/ruby/build/../set.c:769:5 #30 0x632e6e93a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #31 0x632e6e92304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #32 0x632e6e922b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #33 0x632e6e8ea539 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #34 0x632e6e8ea539 in vm_exec_core /media/test/ruby/build/../insns.def:851:11 #35 0x632e6e8dfcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #36 0x632e6e59bbf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #37 0x632e6e59bbf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #38 0x632e6e5972b0 in rb_main /media/test/ruby/build/../main.c:42:12 #39 0x632e6e5972b0 in main /media/test/ruby/build/../main.c:62:12 #40 0x7a1fdf62a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #41 0x7a1fdf62a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #42 0x632e6e4bdd94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) previously allocated by thread T0 here: #0 0x632e6e558be3 in malloc (/media/test/ruby/build/ruby+0x1e6be3) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) #1 0x632e6e5ffdf5 in rb_gc_impl_malloc /media/test/ruby/build/../gc/default/default.c:8114:5 #2 0x632e6e5ce9f2 in ruby_xmalloc_body /media/test/ruby/build/../gc.c:5116:12 #3 0x632e6e5ce9f2 in ruby_xmalloc /media/test/ruby/build/../gc.c:5106:34 #4 0x632e6e7f8586 in set_init_existing_table_with_size /media/test/ruby/build/../st.c:2442:40 #5 0x632e6e7f8586 in rb_set_init_table_with_size /media/test/ruby/build/../st.c:2457:5 #6 0x632e6e7f93d5 in set_rebuild_table /media/test/ruby/build/../st.c:2539:19 #7 0x632e6e7f93d5 in set_rebuild_table_if_necessary /media/test/ruby/build/../st.c:2876:9 #8 0x632e6e7f93d5 in rb_set_insert /media/test/ruby/build/../st.c:2894:5 #9 0x632e6e7fdfdb in set_table_insert_wb /media/test/ruby/build/../set.c:378:15 #10 0x632e6e7fdfdb in set_i_initialize /media/test/ruby/build/../set.c:503:17 #11 0x632e6e93a9db in vm_call_cfunc_with_frame_ /media/test/ruby/build/../vm_insnhelper.c:3798:11 #12 0x632e6e92304a in vm_call_method_each_type /media/test/ruby/build/../vm_insnhelper.c:4776:16 #13 0x632e6e922b13 in vm_call_method /media/test/ruby/build/../vm_insnhelper.c #14 0x632e6e8e76f3 in vm_sendish /media/test/ruby/build/../vm_insnhelper.c:5995:15 #15 0x632e6e8e76f3 in vm_exec_core /media/test/ruby/build/../insns.def:899:11 #16 0x632e6e8dfcd7 in rb_vm_exec /media/test/ruby/build/../vm.c #17 0x632e6e59bbf0 in rb_ec_exec_node /media/test/ruby/build/../eval.c:281:9 #18 0x632e6e59bbf0 in ruby_run_node /media/test/ruby/build/../eval.c:319:30 #19 0x632e6e5972b0 in rb_main /media/test/ruby/build/../main.c:42:12 #20 0x632e6e5972b0 in main /media/test/ruby/build/../main.c:62:12 #21 0x7a1fdf62a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #22 0x7a1fdf62a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #23 0x632e6e4bdd94 in _start (/media/test/ruby/build/ruby+0x14bd94) (BuildId: 5c3c6444d00499cf0254892dbef6454db4a9698a) SUMMARY: AddressSanitizer: heap-use-after-free /media/test/ruby/build/../st.c:3047:13 in set_general_foreach Shadow bytes around the buggy address: 0x511000009b00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x511000009b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x511000009c00: fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa 0x511000009c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x511000009d00: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa =>0x511000009d80: fa fa fa fa fa fa fa fa fd fd[fd]fd fd fd fd fd 0x511000009e00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x511000009e80: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x511000009f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x511000009f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51100000a000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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 ==229421==ABORTING triaged/set_delete_if.rb:21: [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 :delete_if c:0002 p:0042 s:0006 e:000005 EVAL triaged/set_delete_if.rb:21 [FINISH] c:0001 p:0000 s:0003 E:000be0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- triaged/set_delete_if.rb:21:in '<main>' triaged/set_delete_if.rb:21:in 'delete_if' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ./ruby(___interceptor_backtrace) [0x632e6e5026aa] /media/test/ruby/build/ruby(rb_print_backtrace+0x14) [0x632e6ec75c97] /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) [0x632e6ebca16c] /media/test/ruby/build/../error.c:1097 /media/test/ruby/build/ruby(rb_bug_without_die+0x127) [0x632e6ebc9e87] /media/test/ruby/build/../error.c:1106 ./ruby(0x632e6e57d2aa) [0x632e6e57d2aa] ./ruby(0x632e6e55da2f) [0x632e6e55da2f] ./ruby(0x632e6e560ab5) [0x632e6e560ab5] ./ruby(__asan_report_load8) [0x632e6e56181c] /media/test/ruby/build/ruby(set_general_foreach+0x120d) [0x632e6e7fc01d] /media/test/ruby/build/../st.c:3047 /media/test/ruby/build/ruby(set_foreach_call+0x40) [0x632e6e802700] /media/test/ruby/build/../set.c:329 /media/test/ruby/build/ruby(rb_ensure+0x257) [0x632e6e59e5c7] /media/test/ruby/build/../eval.c:1074 /media/test/ruby/build/ruby(set_iter+0x28d) [0x632e6e80247d] /media/test/ruby/build/../set.c:352 /media/test/ruby/build/ruby(iter_lev_in_flags+0x0) [0x632e6e7ff9f5] /media/test/ruby/build/../set.c:769 /media/test/ruby/build/ruby(set_iterating_p) /media/test/ruby/build/../set.c:243 /media/test/ruby/build/ruby(set_compact_after_delete) /media/test/ruby/build/../set.c:366 /media/test/ruby/build/ruby(set_i_delete_if) /media/test/ruby/build/../set.c:770 /media/test/ruby/build/ruby(vm_cfp_consistent_p+0x0) [0x632e6e93a9dc] ../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) [0x632e6e92304b] ../vm_insnhelper.c:4776 ./ruby(vm_call_method+0x2d4) [0x632e6e922b14] /media/test/ruby/build/ruby(vm_sendish+0x11f) [0x632e6e8ea53a] ../vm_insnhelper.c:5995 /media/test/ruby/build/ruby(vm_exec_core) ../insns.def:851 ./ruby(vm_exec_loop+0x0) [0x632e6e8dfcd8] /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) [0x632e6e59bbf1] /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) [0x632e6e5972b1] /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) [0x7a1fdf62a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x7a1fdf62a28b] ../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) [0x632e6e4bdd95] -- Other runtime information ----------------------------------------------- * Loaded script: triaged/set_delete_if.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/

2 1

[ruby-core:122059] [Ruby Bug#17624] Ractor.receive is not thread-safe
by luke-gru (Luke Gruber) 13 May '25

13 May '25

Issue #17624 has been updated by luke-gru (Luke Gruber). Related to https://bugs.ruby-lang.org/issues/21037 ---------------------------------------- Bug #17624: Ractor.receive is not thread-safe https://bugs.ruby-lang.org/issues/17624#change-113207 * Author: dazuma (Daniel Azuma) * Status: Assigned * 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

[ruby-core:111809] [Ruby master Bug#19338] Ruby hangs when defining new constant in ractor
by luke-gru (Luke Gruber) 13 May '25

13 May '25

Issue #19338 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19338: Ruby hangs when defining new constant in ractor https://bugs.ruby-lang.org/issues/19338 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This code causes Ruby to hang: ``` ruby rs = [] 2.times do rs << Ractor.new do MYCONSTANT = 2 end end rs.each(&:take) ``` There is a problem when the warning is being outputted with multiple ractors. A thread is calling RB_VM_LOCK() while holding the VM lock in ractor.c (ractor_check_blocking()) If the code is changed to RB_VM_LOCK_ENTER() and RB_VM_LOCK_LEAVE() then it fixes it, but I don't know if there's a better way. Thanks! -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121829] [Ruby Feature#21308] Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm
by watson1978 (Shizuo Fujita) 13 May '25

13 May '25

Issue #21308 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Feature #21308: Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm https://bugs.ruby-lang.org/issues/21308 * Author: watson1978 (Shizuo Fujita) * Status: Open ---------------------------------------- This is a feature request to replace Ruby's `Float#to_s` implementation with a modern high-performance float-to-string conversion algorithm such as Grisu. Currently, `Float#to_s` in Ruby uses the BSD-derived implementation in [missing/dtoa.c](https://github.com/ruby/ruby/blob/master/missing/dtoa.c). Meanwhile, `json` gem has adopted a Grisu-based implementation in [ruby/json#768](https://github.com/ruby/json/pull/768), it has been improve the performance of float-to-string conversion dramatically. It appears to have brought about a 10 times improvement in performance. However, the improvement is limited to the `json` gem. If we can use the same implementation in `Float#to_s`, it will introduce the improvement in all float-to-string conversion cases. (In additional, it would be better if an API could be added that could be called directly from the C extension library, it will reduce the overhead of the call.) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118467] [Ruby master Feature#20610] Float::INFINITY as IO.select timeout argument
by akr (Akira Tanaka) 13 May '25

13 May '25

Issue #20610 has been reported by akr (Akira Tanaka). ---------------------------------------- Feature #20610: Float::INFINITY as IO.select timeout argument https://bugs.ruby-lang.org/issues/20610 * Author: akr (Akira Tanaka) * Status: Open ---------------------------------------- I propose IO.select accepts Float::INFINITY as a timeout argument. It behaves the same as nil which means IO.select will block indefinitely. Motivation: Currently, the Ruby convention to indicate no timeout is using nil. This practice often forces us to treat the nil case separately. Conceptually, no timeout can be thought of as an infinite timeout. So I propose to accept Float::INFINITY as a timeout. It makes us less conditionals when we need to calculate or compare timeouts. Assume `now` method as follows to read the following examples. ``` def now = Process.clock_gettime(Process::CLOCK_MONOTONIC) ``` Example 1: absolute timeout Sometimes we maintain timeout as an absolute clock. The following method takes a relative timeout as an argument. It invokes IO.select several times and raises if the timeout is reached. Assuming a user must specify a finite timeout, the following definition is possible. ``` # user_timeout is the required argument def method(..., user_timeout) abs_timeout = now + user_timeout loop { IO.select(rs, ws, es, (abs_timeout - now).clamp(0..)) raise "timeout" if abs_timeout < now ... } end ``` Consider we need to make user_timeout optional. If user_timeout is not given, no timeout occurs. The implementation is as follows. I think the following implementation is typical. It needs 3 more conditionals than the above. ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : nil loop { IO.select(rs, ws, es, user_timeout ? (abs_timeout - now).clamp(0..) : nil) raise "timeout" if abs_timeout && (abs_timeout < now) ... } end ``` It is possible to reduce a conditional if we use Float::INFINITY. (`abs_timeout && (abs_timeout < now)` is changed to `abs_timeout < now`) ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : Float::INFINITY loop { IO.select(rs, ws, es, abs_timeout != Float::INFINITY ? (abs_timeout - now).clamp(0..) : nil) raise "timeout" if abs_timeout < now ... } end ``` If IO.select accepts Float::INFINITY as a timeout argument (this proposal), we can reduce one more conditional as follows. ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : Float::INFINITY loop { IO.select(rs, ws, es, (abs_timeout - now).clamp(0..)) raise "timeout" if abs_timeout < now ... } end ``` Example 2: minimum of timeouts Sometimes we need to choose the minimum of several timeouts. I think many event-driven programs use this strategy to determine the timeout for select function. If "no timeout" is represented as nil, `[t1, t2, t3, ...].compact.min` is the minimum. If "no timeout" is represented as Float::INFINITY, we can remove `compact`: `[t1, t2, t3, ...].min` However, Float::INFINITY must be converted to nil for IO.select. This proposal removes this conversion. Example 3: maximum of timeouts Sometimes we need to choose the maximum of several timeouts. We encountered this situation with a Happy Eyeballs implementation. There are two timeouts for getaddrinfo and connect. We need to wait the longer timeout because a timeout for one doesn't stop another. Also, we don't ignore results after a timeout as long as the algorithm waits for something. If "no timeout" is represented as nil, `ts = [t1, t2, t3, ...]; ts.include?(nil) ? nil : ts.max` is the maximum. If "no timeout" is represented as Float::INFINITY, we can compute the maximum more easily: `[t1, t2, t3, ...].max` It makes code simpler. However, Float::INFINITY must be converted to nil for IO.select. This proposal removes this conversion. Several Consideration: Consideration 1: Methods other than IO.select. Several methods take a timeout. An incomplete list of methods is as follows. (I searched rb_time_interval.) - IO.select(rs, ws, es, timeout) - sleep(secs) - TCPSocket.new(connect_timeout:) - io.wait_readable(timeout) - io.wait_writable(timeout) - io.wait_priority(timeout) - mutex.sleep(timeout) Do we want to modify them consistently to accept Float::INFINITY? Consideration 2: C-level API If we want to change the timeout of many methods, we would wish to new C-level API similar to rb_time_interval but can return NULL. Unfortunately, rb_time_interval cannot return NULL because the return type is struct timeval. Note that ext/io/wait/wait.c contains get_timeout function. It seems a good first step for such API. Consideration 3: IEEE 754 dependency. Minor platforms (such as VAX) use non-IEEE 754 floating point numbers without infinity. Note that NetBSD/vax still works. (And there is an emulator, simh). Consideration 4: It seems no major languages accept infinity as select's timeout. I found Perl, Python, and OCaml take a floating point number as a timeout of select function. But they don't accept infinity. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:121702] [Ruby Bug#21280] StringIO#set_encoding warns when backed by chilled string literal
by jeremyevans0 (Jeremy Evans) 13 May '25

13 May '25

Issue #21280 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21280: StringIO#set_encoding warns when backed by chilled string literal https://bugs.ruby-lang.org/issues/21280 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `StringIO#set_encoding` changes the underlying string encoding if the string is not frozen, but does not change the underlying string encoding if the string is frozen. In Ruby 3.4, this results in a warning for chilled literal strings: ``` $ ruby34 -w -r stringio -e "StringIO.new('').set_encoding('binary')" -e:1: warning: literal string will be frozen in the future (run with --debug-frozen-string-literal for more information) ``` I believe Ruby should emit this warning only for cases that will break when string literals are frozen. This is not one of those cases, so Ruby should not emit the warning. To avoid emitting the warning, I think `StringIO#set_encoding` should not set the encoding on the underlying string for chilled literal strings. I submitted a pull request to avoid changing the encoding of the underlying string: https://github.com/ruby/stringio/pull/128 However, @rhenium said that he thought the encoding of the underlying string should still be changed, and the warning should be emitted (https://github.com/ruby/stringio/pull/128#issuecomment-2818362875) For some history, before Ruby 2.3, `StringIO#set_encoding` used to always set the encoding of the underlying string. This was changed in #11827, when the encoding was not set on the underlying string if the string was frozen (commit:3e1c01ae463a8c9d8bbe9050251a2538ddb0292f). In https://bugs.ruby-lang.org/issues/11827#note-3, @nurse wrote: > Away from the case and thinking ideal behavior, StringIO should be a view of given source string and set_encoding shouldn't change source encoding. > But I'm not sure that it is worth breaking the compatibility. I think this means that ideally, absent backwards compatibility issues, StringIO#set_encoding should never change the underlying string encoding. In https://bugs.ruby-lang.org/issues/11827#note-4, @shugo gave an example from @nobu that open-uri depends on the current behavior: ```ruby enc = Encoding::ASCII_8BIT unless enc if self.respond_to? :force_encoding self.force_encoding(enc) elsif self.respond_to? :string self.string.force_encoding(enc) else # Tempfile self.set_encoding enc end end ``` However, as `StringIO#string` is defined, this will call `self.string.force_encoding(enc)` and not `self.set_encoding enc`, so I'm not sure why a change to `String#set_encoding` would affect the behavior of this example. @rhenium pointed out that this issue affects `StringIO#binmode` and `StringIO#set_encoding_by_bom` as well as `StringIO#encoding`. How do we want to handle this case? Should this result in a warning (current behavior), or is it safe to avoid changing the encoding of the underlying string for chilled strings (as is done for frozen strings)? -- https://bugs.ruby-lang.org/

4 12

[ruby-core:121745] [Ruby Bug#21286] Windows - MSYS2 just updated to GCC 15.1.0, builds failing
by MSP-Greg (Greg L) 13 May '25

13 May '25

Issue #21286 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21286: Windows - MSYS2 just updated to GCC 15.1.0, builds failing https://bugs.ruby-lang.org/issues/21286 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: master * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- MSYS2 just updated to GCC 15.1.0, and the ruby-loco builds failed to compile. See [MinGW](https://github.com/MSP-Greg/ruby-loco/actions/runs/14693708990/job/4… & [UCRT](https://github.com/MSP-Greg/ruby-loco/actions/runs/14693775816/job/41… Also, I compiled mswin locally with the recent VS 'preview' release, and the bug has been fixed. -- https://bugs.ruby-lang.org/

10 14