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

[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:121988] [Ruby Bug#21324] Namespace loads RubyGems in root Namespace but it should not
by Eregon (Benoit Daloze) 13 May '25

13 May '25

Issue #21324 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21324: Namespace loads RubyGems in root Namespace but it should not https://bugs.ruby-lang.org/issues/21324 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- RubyGems has tons of mutable state, isn't core library and isn't "builtin classes" either, so it should not be in root Namespace, as it is currently: ``` $ RUBY_NAMESPACE=1 ruby -ve 'ns = Namespace.new; p ns::Gem.equal?(Gem)' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. true ``` A concrete example of what breaks most likely due to this: ``` $ gem i delegate:0.3.1 $ RUBY_NAMESPACE=1 ruby -ve 'require "delegate"; p Delegator::VERSION; ns = Namespace.new; File.write "ns.rb", "gem %{delegate}, %{0.3.1}; require :delegate.to_s; p Delegator::VERSION"; ns.require "./ns"' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. "0.4.0" /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:2232:in 'Gem::Specification#check_version_conflict': can't activate delegate-0.3.1, already activated delegate-0.4.0 (Gem::LoadError) from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:1383:in 'Gem::Specification#activate' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'block in Kernel#gem' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Thread::Mutex#synchronize' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Kernel#gem' from /home/eregon/ns.rb:1:in '<top (required)>' from -e:1:in 'Namespace#require' from -e:1:in '<main>' ``` i.e. `ns` sees delegate-0.4.0 was loaded in main namespace but it shouldn't. Previously mentioned in https://bugs.ruby-lang.org/issues/21311#note-36 -- https://bugs.ruby-lang.org/

3 4

[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

[ruby-core:121804] [Ruby Bug#21302] Remove or Fix Set#to_h
by jeremyevans0 (Jeremy Evans) 13 May '25

13 May '25

Issue #21302 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21302: Remove or Fix Set#to_h https://bugs.ruby-lang.org/issues/21302 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When backwards-compatible marshalling support for Set was added in commit:926411171d296859839745a536aa86bc1e18aa76, Set#to_h was added. I'm not sure if intentionally or accidentally (@nobu knows). The method is not backwards compatible with the previous Set#to_h method (Enumerable#to_h), so it should be fixed or removed. Since it is a new method added to a core class, it should be officially approved if we want to keep it. I would prefer removing it. Users that want a `true`-valued hash can use `to_h { [it, true] }` instead of `to_h`. I have submitted a pull request to remove it: https://github.com/ruby/ruby/pull/13247 However, if we want to keep it, we should fix it to be backwards compatible and add tests and documentation. I have submitted a pull request for that as well: https://github.com/ruby/ruby/pull/13248 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122017] [Ruby Bug#21328] Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
by fagrela (Felipe Agrela) 11 May '25

11 May '25

Issue #21328 has been reported by fagrela (Felipe Agrela). ---------------------------------------- Bug #21328: Gem::Ext::BuildError: ERROR: Failed to build gem native extension. https://bugs.ruby-lang.org/issues/21328 * Author: fagrela (Felipe Agrela) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We are facing an issue that starts in 05/03/2025 We have an Azure Devops Pipeline that build and test a project, but in the test step we have the following error: Gem::Ext::BuildError: ERROR: Failed to build gem native extension. C:/hostedtoolcache/windows/Ruby/3.3.8/x64/lib/ruby/gems/3.3.0/gems/ffi-1.16.3/ext/ffi_c '/c/hostedtoolcache/windows/Ruby/3.3.8/x64/lib/ruby/gems/3.3.0/gems/ffi-1.16.3/ext/ffi_c/libffi-x64-mingw-ucrt' 2025-05-08T20:17:16.1292182Z compiling AbstractMemory.c 2025-05-08T20:17:16.1293918Z AbstractMemory.c: In function 'rbffi_AbstractMemory_Init': 2025-05-08T20:17:16.1379827Z AbstractMemory.c(816,49): error G9F317667: passing argument 3 of 'rb_define_method' from [C:\Users\VssAdministrator\.nuget\packages\gcm.msbuild.sdk\8.0.10-platform-debuggi0004\build\Chef\ChefDependencies.proj] [D:\a\1\s\Tests\ChefUnitTests\ChefUnitTests.csproj] 2025-05-08T20:17:16.1382541Z incompatible pointer type [-Wincompatible-pointer-types] 2025-05-08T20:17:16.1384491Z 816 | rb_define_method(classMemory, "put_" #type, memory_put_##type, 2); \ 2025-05-08T20:17:16.1386316Z | ^~~~~~~~~~~ 2025-05-08T20:17:16.1388056Z | | 2025-05-08T20:17:16.1389784Z | VALUE (*)(VALUE, VALUE, 2025-05-08T20:17:16.1391627Z VALUE) {aka long long unsigned int (*)(long long unsigned int, long long 2025-05-08T20:17:16.1393395Z unsigned int, long long unsigned int)} 2025-05-08T20:17:16.1395349Z AbstractMemory.c:833:5: note: in expansion of macro 'INT' 2025-05-08T20:17:16.1397142Z 833 | INT(int8); 2025-05-08T20:17:16.1398853Z | ^~~ 2025-05-08T20:17:16.1400582Z In file included from 2025-05-08T20:17:16.1402347Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby/internal/anyargs.h:78, 2025-05-08T20:17:16.1404181Z from 2025-05-08T20:17:16.1406077Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby/ruby.h:27, 2025-05-08T20:17:16.1407838Z from 2025-05-08T20:17:16.1409590Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby.h:38, 2025-05-08T20:17:16.1411368Z from AbstractMemory.c:40: 2025-05-08T20:17:16.1413229Z C:/hostedtoolcache/windows/Ruby/3.3.8/x64/include/ruby-3.3.0/ruby/internal/method.h:99:61: 2025-05-08T20:17:16.1415037Z note: expected 'VALUE (*)(void)' {aka 'long long unsigned int (*)(void)'} but 2025-05-08T20:17:16.1417112Z argument is of type 'VALUE (*)(VALUE, VALUE, VALUE)' {aka 'long long unsigned 2025-05-08T20:17:16.1419032Z int (*)(long long unsigned int, long long unsigned int, long long unsigned 2025-05-08T20:17:16.1420785Z int)'} 2025-05-08T20:17:16.1422532Z 99 | void rb_define_method(VALUE klass, const char *mid, VALUE 2025-05-08T20:17:16.1424350Z (*func)(ANYARGS), int arity); 2025-05-08T20:17:16.1427260Z | 2025-05-08T20:17:16.1429021Z ~~~~~~~~^~~~~~~~~~~~~~ 2025-05-08T20:17:16.1430845Z AbstractMemory.c:96:1: note: 'memory_put_int8' declared here 2025-05-08T20:17:16.1432652Z 96 | memory_put_##name(VALUE self, VALUE offset, VALUE value) \ 2025-05-08T20:17:16.1434412Z | ^~~~~~~~~~~ 2025-05-08T20:17:16.1436168Z AbstractMemory.c:259:1: note: in expansion of macro 'NUM_OP' 2025-05-08T20:17:16.1438040Z 259 | NUM_OP(int8, int8_t, NUM2INT, INT2NUM, NOSWAP); 2025-05-08T20:17:16.1439757Z | ^~~~~~ 2025-05-08T20:17:16.1446346Z AbstractMemory.c(817,49): error G9F317667: passing argument 3 of 'rb_define_method' from [C:\Users\VssAdministrator\.nuget\packages\gcm.msbuild.sdk\8.0.10-platform-debuggi0004\build\Chef\ChefDependencies.proj] [D:\a\1\s\Tests\ChefUnitTests\ChefUnitTests.csproj] 2025-05-08T20:17:16.1448813Z incompatible pointer type [-Wincompatible-pointer-types] 2025-05-08T20:17:16.1450695Z 817 | rb_define_method(classMemory, "get_" #type, memory_get_##type, 1); \ 2025-05-08T20:17:16.1452471Z | ^~~~~~~~~~~ 2025-05-08T20:17:16.1454208Z | | 2025-05-08T20:17:16.1455919Z | VALUE (*)(VALUE, VALUE) 2025-05-08T20:17:16.1457703Z {aka long long unsigned int (*)(long long unsigned int, long long unsigned 2025-05-08T20:17:16.1459434Z int)} 2025-05-08T20:17:16.1461252Z AbstractMemory.c:833:5: note: in expansion of macro 'INT' 2025-05-08T20:17:16.1463024Z 833 | INT(int8); 2025-05-08T20:17:16.1464707Z | ^~~ Any ideas or how can we fix that? -- https://bugs.ruby-lang.org/

2 2