- ruby-core - ml.ruby-lang.org

[ruby-core:122094] [Ruby Bug#17998] ractor: process hanging (with ractors initialized, but not being used)
by byroot (Jean Boussier) 14 May '25

14 May '25

Issue #17998 has been updated by byroot (Jean Boussier). Status changed from Assigned to Closed The reproduction steps aren't very clear to me. But the backtrace shows `fork` and `finalizers` are involved. Since Ractors received fixes around this area recently and the issue date back to 3.0.1, I'm going to assume it has been fixed. If not we're likely to run into it soon. ---------------------------------------- Bug #17998: ractor: process hanging (with ractors initialized, but not being used) https://bugs.ruby-lang.org/issues/17998#change-113248 * Author: chucke (Tiago Cardoso) * Status: Closed * Assignee: ractor * ruby -v: 3.0.1 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I couldn't figure out how to reproduce this in a more contained way, so I'll share what I'm doing [in this minitest branch](https://github.com/HoneyryderChuck/minitest/tree/issue-872). I'm trying to make minitest's parallel mode use ractors. If you look at the last commit of the branch, I'm: * replacing the parallel executor with a ractor-based one; * I'm defining the ractor executor, where I have a ractor pipe that a pool will consume work from * I'm turning off parallel subset of tests (to reproduce the bug that I'll be describing). When I run `rake test` in my Mac (BigSur 11.4), the process hangs. I can see that the ractor threads are executing and running, but the test process doesn't respond to the INFO signal interrupt (which should tell me where the process is hanging). This seems like a bug in the VM, as no work is being sent to the parallel executor, i.e. all ractors should be sleeping (I've `puts`'d also the executor shutdown process, and it never reaches it). If I replace the ractor-based executor back with the thread based executor, everything works as expected. ---Files-------------------------------- bug17998-0001.log (58.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122093] [Ruby Bug#17420] Unsafe mutation of $" when doing non-RubyGems require in Ractor
by byroot (Jean Boussier) 14 May '25

14 May '25

Issue #17420 has been updated by byroot (Jean Boussier). Status changed from Assigned to Closed I hope I'm not misinterpreting the ticket. Since https://github.com/ruby/ruby/pull/11142 you can now require from a Ractor. `$"` is of course still not readable from a background ractor, but I think the ticket was really about `require`. ---------------------------------------- Bug #17420: Unsafe mutation of $" when doing non-RubyGems require in Ractor https://bugs.ruby-lang.org/issues/17420#change-113247 * 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:122092] [Ruby Bug#17677] Ractor crashes fork when blocking
by byroot (Jean Boussier) 14 May '25

14 May '25

Issue #17677 has been updated by byroot (Jean Boussier). Status changed from Assigned to Closed I can't reproduce on master nor on any version since 3.0.3. I'm going to assume this was fixed. ---------------------------------------- Bug #17677: Ractor crashes fork when blocking https://bugs.ruby-lang.org/issues/17677#change-113246 * Author: delner (David Elner) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Background If you create a Ractor which blocks (e.g. `receive`), then fork the process, the fork will segfault upon completion. ## How to reproduce ```ruby r2 = Ractor.new do Ractor.receive end sleep(1) puts "Forking..." fork do sleep(1) puts "End fork." end loop do puts "Main thread." sleep(1) end ``` ## Expectation and result Application prints “Main thread” from main process every second, while fork prints “End fork.” then produces a segfault. Main process continues to run. Expected fork to not raise a segfault. ``` <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. Forking... Main thread. Main thread. End fork. app/sandbox.rb:80: [BUG]: Device or resource busy (EBUSY) ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :fork c:0002 p:0048 s:0007 E:001b48 EVAL app/sandbox.rb:80 [FINISH] c:0001 p:0000 s:0003 E:002590 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- app/sandbox.rb:80:in `<main>' app/sandbox.rb:80:in `fork' -- C level backtrace information ------------------------------------------- /usr/local/lib/libruby.so.3.0(rb_print_backtrace+0x11) [0x7f9848528cfb] vm_dump.c:758 /usr/local/lib/libruby.so.3.0(rb_vm_bugreport) vm_dump.c:998 /usr/local/lib/libruby.so.3.0(bug_report_end+0x0) [0x7f9848354808] error.c:763 /usr/local/lib/libruby.so.3.0(rb_bug_without_die) error.c:763 /usr/local/lib/libruby.so.3.0(die+0x0) [0x7f98482c6902] error.c:771 /usr/local/lib/libruby.so.3.0(rb_bug) error.c:773 /usr/local/lib/libruby.so.3.0(rb_bug_errno+0x3c) [0x7f9848354a1c] error.c:802 /usr/local/lib/libruby.so.3.0(rb_native_mutex_destroy+0x20) [0x7f98484ce380] thread_pthread.c:444 /usr/local/lib/libruby.so.3.0(rb_native_cond_initialize) (null):0 /usr/local/lib/libruby.so.3.0(ractor_free+0xd) [0x7f984844487d] ractor.c:229 /usr/local/lib/libruby.so.3.0(run_final+0xb) [0x7f9848371c66] gc.c:3670 /usr/local/lib/libruby.so.3.0(finalize_list) gc.c:3689 /usr/local/lib/libruby.so.3.0(rb_objspace_call_finalizer+0x33d) [0x7f984837cc5d] gc.c:3852 /usr/local/lib/libruby.so.3.0(rb_ec_cleanup+0x311) [0x7f984835f0b1] eval.c:184 /usr/local/lib/libruby.so.3.0(ruby_stop+0x9) [0x7f984835f339] eval.c:329 /usr/local/lib/libruby.so.3.0(rb_f_fork+0x1f) [0x7f98484402f8] process.c:4348 /usr/local/lib/libruby.so.3.0(rb_f_fork) process.c:4338 /usr/local/lib/libruby.so.3.0(vm_call_cfunc_with_frame+0x11b) [0x7f984850672b] vm_insnhelper.c:2898 /usr/local/lib/libruby.so.3.0(vm_call_method_each_type+0xf9) [0x7f98485192c9] vm_insnhelper.c:3388 /usr/local/lib/libruby.so.3.0(vm_call_method+0xb4) [0x7f9848519b24] vm_insnhelper.c:3506 /usr/local/lib/libruby.so.3.0(vm_sendish+0xb3) [0x7f984850a3d3] vm_insnhelper.c:4499 /usr/local/lib/libruby.so.3.0(vm_exec_core+0x140) [0x7f98485123e0] insns.def:770 /usr/local/lib/libruby.so.3.0(rb_vm_exec+0x176) [0x7f9848517b26] vm.c:2163 /usr/local/lib/libruby.so.3.0(rb_ec_exec_node+0xd9) [0x7f9848359719] eval.c:317 /usr/local/lib/libruby.so.3.0(ruby_run_node+0x55) [0x7f984835f395] eval.c:375 /usr/local/bin/ruby(main+0x5b) [0x565147e5410b] ./main.c:50 ... Main thread. Main thread. Main thread. ``` ## Additional notes This does not happen if a blocking operation does not occur in the Ractor. E.g. ```ruby r2 = Ractor.new do loop { puts "[#{Process.pid}] Ractor"; sleep(1) } end ``` Segfault can also be prevented by invoking `close_incoming` prior to forking, although this raises another error internally. It also does not crash on MacOS 10.15.7: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin19]. ## Suggested solutions (None) -- https://bugs.ruby-lang.org/

1 0

[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) 14 May '25

14 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: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