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

[ruby-core:122098] [Ruby Bug#21339] Namespace: `RubyVM::InstructionSequence.load_iseq` isn't called for the root namespace
by byroot (Jean Boussier) 15 May '25

15 May '25

Issue #21339 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21339: Namespace: `RubyVM::InstructionSequence.load_iseq` isn't called for the root namespace https://bugs.ruby-lang.org/issues/21339 * Author: byroot (Jean Boussier) * Status: Assigned * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 3.5.0dev (2025-05-14T12:41:46Z master b5575a80bc) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby File.write("/tmp/compile-cache.rb", <<~'RUBY') class << RubyVM::InstructionSequence def load_iseq(path) p [:load_iseq, path] RubyVM::InstructionSequence.compile_file(path) end end RUBY File.write("/tmp/test-file.rb", "") puts "main:" require "/tmp/compile-cache.rb" require "/tmp/test-file.rb" if ENV["RUBY_NAMESPACE"] puts "namespace:" ns = Namespace.new ns.require("/tmp/compile-cache.rb") ns.require("/tmp/test-file.rb") end ``` Expected behavior: I would expect `load_iseq` to be invoked both in the root namespace and the user namespace when `RUBY_NAMESPACE=1`. Actual behavior: Somehow it's only invoked in the user namespace: ```bash main: [:compile_cache_setup] [:load_iseq, "/tmp/test-file.rb"] ``` ```bash main: [:compile_cache_setup] namespace: [:compile_cache_setup] [:load_iseq, "/tmp/test-file.rb"] ``` But I don't understand why. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122109] [Ruby Bug#17420] Unsafe mutation of $" when doing non-RubyGems require in Ractor
by Eregon (Benoit Daloze) 14 May '25

14 May '25

Issue #17420 has been updated by Eregon (Benoit Daloze). Yep, the original ticket was about incorrectly allowing `require` in Ractors and that could segfault. https://github.com/ruby/ruby/pull/11142 is the proper fix. ---------------------------------------- Bug #17420: Unsafe mutation of $" when doing non-RubyGems require in Ractor https://bugs.ruby-lang.org/issues/17420#change-113262 * Author: Eregon (Benoit Daloze) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.0.0dev (2020-12-16T10:12:48Z master a9a7f4d8b8) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- With an empty file `a.rb`: ``` $ ruby --disable-gems -e 'Ractor.new { puts $" }.take' -e:1:in `block in <main>': can not access global variables $" from non-main Ractors (RuntimeError) ``` That is expected, given the rules for global variables. ``` ruby --disable-gems -e 'Ractor.new { require "./a.rb"; }.take; p $"' [... , "/home/eregon/a.rb"] ``` Is it OK that the Ractor can do `require`, which does modify `$"`? I think it's not, and it might lead to segfaults if e.g. the main Ractor mutates `$"` in parallel to some other Ractor doing `require`. Probably `require` needs to be forbidden in non-main Ractors (it does mutate `$"`, so it's logical), or there needs to be always VM-global synchronization on any access to `$"` (otherwise, segfaults are possible). The latter doesn't seem reasonable, especially when considering the user might do `$".each { ... }`. --- Note that RubyGems' `require` does not work on non-main Ractors (pretty much expected given it depends on a lot of global state): ``` $ ruby -e 'Ractor.new { require "./a.rb"; }.take' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (NameError) ``` This probably also has consequences for `autoload`. Maybe the `zeitwerk` gem can help with the mode to resolve all autoload at once. -- https://bugs.ruby-lang.org/

1 0

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

14 May '25

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

2 5

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

14 May '25

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

1 0

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

14 May '25

Issue #17624 has been updated by luke-gru (Luke Gruber). I didn't tag the commit message properly, but this can be closed. PR https://github.com/ruby/ruby/pull/12633 was merged. Thanks! ---------------------------------------- Bug #17624: Ractor.receive is not thread-safe https://bugs.ruby-lang.org/issues/17624#change-113256 * 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:119137] [Ruby master Bug#20726] Issue with hash without braces when assigned to constant with ractor literals
by luke-gru (Luke Gruber) 14 May '25

14 May '25

Issue #20726 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20726: Issue with hash without braces when assigned to constant with ractor literals https://bugs.ruby-lang.org/issues/20726 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.0dev * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby a = 'hi' A = ['hello' => a] p A ``` gives: ``` ./ruby -I../ruby/lib -I. -I.ext/x86_64-linux -I.ext/common -r./x86_64-linux-fake ../ruby/test.rb -- raw disasm-------- trace: 1 0000 putchilledstring "hi" ( 3) 0002 setlocal_WC_0 3 ( 3) trace: 1 0004 newarray 1 ( 4) 0006 putspecialobject 3 ( 4) * 0008 setconstant :A ( 4) trace: 1 0010 putself ( 5) 0011 opt_getconstant_path [:A] ( 5) 0013 opt_send_without_block <calldata:p, 1> ( 5) 0015 leave ( 5) --------------------- ../ruby/test.rb:4: argument stack underflow (-1) ../ruby/test.rb: compile error (SyntaxError) ``` This is due to a line in `compile.c`, function `compile_shareable_literal_constant`: ```c if (!RNODE_HASH(node)->nd_brace) { } ``` I'm not sure why this condition is there so I'm not confident in making a fix. Also, my git-fu isn't the best so I can't track down the right commit where it was added. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:122096] [Ruby Bug#18412] Segfault in test_ractor.rb
by byroot (Jean Boussier) 14 May '25

14 May '25

Issue #18412 has been updated by byroot (Jean Boussier). Status changed from Assigned to Closed This report being about CI failures, I'm going to assume it was fixed otherwise we'd still see it today. ---------------------------------------- Bug #18412: Segfault in test_ractor.rb https://bugs.ruby-lang.org/issues/18412#change-113250 * Author: vo.x (Vit Ondruch) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [powerpc64le-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- During build of Ruby 3.0.3 for Fedora, I sometimes bump into this issue: ~~~ ... snip ... test_attr.rb .. test_autoload.rb ........ test_block.rb .......................................................... test_class.rb ................................................ test_env.rb .. test_eval.rb ..................................... test_exception.rb .................................. test_fiber.rb ..... test_finalizer.rb . test_flip.rb . test_flow.rb .............................................................. test_fork.rb .... test_gc.rb .. test_insns.rb ............................................................................................................................................................................................................................................................................................................................................................................................... test_io.rb ......... test_jump.rb ............................. test_literal.rb ............................................................................................................................................................ test_literal_suffix.rb ................................................ test_load.rb .. test_marshal.rb . test_massign.rb .................................. test_method.rb ............................................................................................................................................................................................................................... test_objectspace.rb ...... test_proc.rb ..................................... test_ractor.rb .........................................................................................Fstderr output is not empty <internal:ractor>:627: [BUG] Segmentation fault at 0x0000000000000038 ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [powerpc64le-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0020 e:000019 METHOD <internal:ractor>:627 c:0004 p:0032 s:0013 e:000012 BLOCK bootstraptest.tmp.rb:6 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :loop c:0002 p:0005 s:0006 e:000005 BLOCK bootstraptest.tmp.rb:4 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- bootstraptest.tmp.rb:4:in `block (2 levels) in <main>' bootstraptest.tmp.rb:4:in `loop' bootstraptest.tmp.rb:6:in `block (3 levels) in <main>' <internal:ractor>:627:in `yield' -- C level backtrace information ------------------------------------------- /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_print_backtrace+0x24) [0x7fffb1dd3604] vm_dump.c:758 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_vm_bugreport.constprop.0+0x5c0) [0x7fffb1df1780] vm_dump.c:998 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_bug_for_fatal_signal+0xa4) [0x7fffb1bbdc74] error.c:786 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(sigsegv+0x68) [0x7fffb1d2a4a8] signal.c:963 [0x7fffb1f80464] [0x7fffb191ad68] /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_native_mutex_lock+0x18) [0x7fffb1d6f558] thread_pthread.c:397 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(ractor_select+0x480) [0x7fffb1cda060] ractor.c:61 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(builtin_inline_class_627.lto_priv.0+0x50) [0x7fffb1cdaa30] ractor.c:1286 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(builtin_invoker0.lto_priv.0+0x24) [0x7fffb1db5624] vm_insnhelper.c:5445 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(vm_exec_core.lto_priv.0+0x254c) [0x7fffb1dbfe6c] insns.def:1493 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_vm_exec+0x130) [0x7fffb1ddc7e0] vm.c:2172 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(loop_i+0x2e4) [0x7fffb1dc7bd4] vm.c:1263 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_vrescue2+0xec) [0x7fffb1bbc6cc] eval.c:1019 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_rescue2+0x3c) [0x7fffb1bbc8bc] eval.c:996 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_f_loop.lto_priv.0+0x58) [0x7fffb1dc87c8] vm_eval.c:1483 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(ractor_safe_call_cfunc_0.lto_priv.0+0x24) [0x7fffb1da7904] vm_insnhelper.c:2748 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(vm_call_cfunc_with_frame+0x150) [0x7fffb1db2650] vm_insnhelper.c:2931 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(vm_sendish.lto_priv.0+0x3dc) [0x7fffb1db7b0c] vm_insnhelper.c:4532 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(vm_exec_core.lto_priv.0+0x1890) [0x7fffb1dbf1b0] insns.def:770 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(rb_vm_exec+0x130) [0x7fffb1ddc7e0] vm.c:2172 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(vm_invoke_proc.lto_priv.0+0x2c0) [0x7fffb1dcfc90] vm.c:1263 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(thread_do_start_proc.lto_priv.0+0x5ac) [0x7fffb1d7852c] vm.c:1499 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(thread_start_func_2.constprop.0.isra.0+0x958) [0x7fffb1dfacf8] thread.c:759 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3(thread_start_func_1+0x180) [0x7fffb1d70070] thread_pthread.c:994 [0x7fffb1916264] [0x7fffb19c5f30] -- Other runtime information ----------------------------------------------- * Loaded script: bootstraptest.tmp.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 rational.so 3 complex.so 4 ruby2_keywords.rb 5 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/encdb.so 6 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/trans/transdb.so 7 /builddir/build/BUILD/ruby-3.0.3/abrt.rb * Process memory map: 102330000-102340000 r--p 00000000 fc:06 1076662947 /builddir/build/BUILD/ruby-3.0.3/ruby 102340000-102350000 r-xp 00010000 fc:06 1076662947 /builddir/build/BUILD/ruby-3.0.3/ruby 102350000-102360000 r--p 00020000 fc:06 1076662947 /builddir/build/BUILD/ruby-3.0.3/ruby 102360000-102370000 r--p 00020000 fc:06 1076662947 /builddir/build/BUILD/ruby-3.0.3/ruby 102370000-102380000 rw-p 00030000 fc:06 1076662947 /builddir/build/BUILD/ruby-3.0.3/ruby 134320000-134530000 rw-p 00000000 00:00 0 [heap] 7fff88000000-7fff88bd0000 rw-p 00000000 00:00 0 7fff88bd0000-7fff8c000000 ---p 00000000 00:00 0 7fff8c000000-7fff8cd90000 rw-p 00000000 00:00 0 7fff8cd90000-7fff90000000 ---p 00000000 00:00 0 7fff90000000-7fff901e0000 rw-p 00000000 00:00 0 7fff901e0000-7fff94000000 ---p 00000000 00:00 0 7fff94000000-7fff94be0000 rw-p 00000000 00:00 0 7fff94be0000-7fff98000000 ---p 00000000 00:00 0 7fff98000000-7fff99320000 rw-p 00000000 00:00 0 7fff99320000-7fff9c000000 ---p 00000000 00:00 0 7fff9c000000-7fff9cc40000 rw-p 00000000 00:00 0 7fff9cc40000-7fffa0000000 ---p 00000000 00:00 0 7fffa0000000-7fffa0d60000 rw-p 00000000 00:00 0 7fffa0d60000-7fffa4000000 ---p 00000000 00:00 0 7fffa7ed0000-7fffa7ee0000 ---p 00000000 00:00 0 7fffa7ee0000-7fffa8000000 rw-p 00000000 00:00 0 7fffa8000000-7fffa91a0000 rw-p 00000000 00:00 0 7fffa91a0000-7fffac000000 ---p 00000000 00:00 0 7fffada60000-7fffadaa0000 r--s 00000000 fc:06 1076662947 /builddir/build/BUILD/ruby-3.0.3/ruby 7fffadaa0000-7fffadab0000 r--p 00000000 fc:06 1614754146 /usr/lib64/libgcc_s-11-20211203.so.1 7fffadab0000-7fffadac0000 r-xp 00010000 fc:06 1614754146 /usr/lib64/libgcc_s-11-20211203.so.1 7fffadac0000-7fffadad0000 r--p 00020000 fc:06 1614754146 /usr/lib64/libgcc_s-11-20211203.so.1 7fffadad0000-7fffadae0000 r--p 00020000 fc:06 1614754146 /usr/lib64/libgcc_s-11-20211203.so.1 7fffadae0000-7fffadaf0000 rw-p 00030000 fc:06 1614754146 /usr/lib64/libgcc_s-11-20211203.so.1 7fffadaf0000-7fffadb00000 ---p 00000000 00:00 0 7fffadb00000-7fffadc20000 rw-p 00000000 00:00 0 7fffadc20000-7fffadc30000 ---p 00000000 00:00 0 7fffadc30000-7fffadd50000 rw-p 00000000 00:00 0 7fffadd50000-7fffadd60000 ---p 00000000 00:00 0 7fffadd60000-7fffade80000 rw-p 00000000 00:00 0 7fffade80000-7fffade90000 ---p 00000000 00:00 0 7fffade90000-7fffadfb0000 rw-p 00000000 00:00 0 7fffadfb0000-7fffadfc0000 ---p 00000000 00:00 0 7fffadfc0000-7fffae0e0000 rw-p 00000000 00:00 0 7fffae0e0000-7fffae0f0000 ---p 00000000 00:00 0 7fffae0f0000-7fffae210000 rw-p 00000000 00:00 0 7fffae210000-7fffae220000 ---p 00000000 00:00 0 7fffae220000-7fffae340000 rw-p 00000000 00:00 0 7fffae340000-7fffae350000 r--p 00000000 fc:06 1616770133 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/trans/transdb.so 7fffae350000-7fffae360000 r-xp 00010000 fc:06 1616770133 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/trans/transdb.so 7fffae360000-7fffae370000 r--p 00020000 fc:06 1616770133 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/trans/transdb.so 7fffae370000-7fffae380000 r--p 00020000 fc:06 1616770133 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/trans/transdb.so 7fffae380000-7fffae390000 rw-p 00000000 00:00 0 7fffae390000-7fffae3a0000 r--p 00000000 fc:06 1076646137 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/encdb.so 7fffae3a0000-7fffae3b0000 r-xp 00010000 fc:06 1076646137 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/encdb.so 7fffae3b0000-7fffae3c0000 r--p 00020000 fc:06 1076646137 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/encdb.so 7fffae3c0000-7fffae3d0000 r--p 00020000 fc:06 1076646137 /builddir/build/BUILD/ruby-3.0.3/.ext/powerpc64le-linux/enc/encdb.so 7fffae3d0000-7fffae3e0000 rw-p 00000000 00:00 0 7fffae3e0000-7fffae3f0000 ---p 00000000 00:00 0 7fffae3f0000-7fffae460000 rw-p 00000000 00:00 0 7fffae460000-7fffae470000 ---p 00000000 00:00 0 7fffae470000-7fffae4e0000 rw-p 00000000 00:00 0 7fffae4e0000-7fffae4f0000 ---p 00000000 00:00 0 7fffae4f0000-7fffae560000 rw-p 00000000 00:00 0 7fffae560000-7fffae570000 ---p 00000000 00:00 0 7fffae570000-7fffae5e0000 rw-p 00000000 00:00 0 7fffae5e0000-7fffae5f0000 ---p 00000000 00:00 0 7fffae5f0000-7fffae660000 rw-p 00000000 00:00 0 7fffae660000-7fffae670000 ---p 00000000 00:00 0 7fffae670000-7fffae6e0000 rw-p 00000000 00:00 0 7fffae6e0000-7fffae6f0000 ---p 00000000 00:00 0 7fffae6f0000-7fffae760000 rw-p 00000000 00:00 0 7fffae760000-7fffae770000 ---p 00000000 00:00 0 7fffae770000-7fffae7e0000 rw-p 00000000 00:00 0 7fffae7e0000-7fffae7f0000 ---p 00000000 00:00 0 7fffae7f0000-7fffae860000 rw-p 00000000 00:00 0 7fffae860000-7fffae870000 ---p 00000000 00:00 0 7fffae870000-7fffae8e0000 rw-p 00000000 00:00 0 7fffae8e0000-7fffae8f0000 ---p 00000000 00:00 0 7fffae8f0000-7fffae960000 rw-p 00000000 00:00 0 7fffae960000-7fffae970000 ---p 00000000 00:00 0 7fffae970000-7fffae9e0000 rw-p 00000000 00:00 0 7fffae9e0000-7fffae9f0000 ---p 00000000 00:00 0 7fffae9f0000-7fffaea60000 rw-p 00000000 00:00 0 7fffaea60000-7fffaea70000 ---p 00000000 00:00 0 7fffaea70000-7fffaeae0000 rw-p 00000000 00:00 0 7fffaeae0000-7fffaeaf0000 ---p 00000000 00:00 0 7fffaeaf0000-7fffaeb60000 rw-p 00000000 00:00 0 7fffaeb60000-7fffaeb70000 ---p 00000000 00:00 0 7fffaeb70000-7fffaebe0000 rw-p 00000000 00:00 0 7fffaebe0000-7fffaebf0000 ---p 00000000 00:00 0 7fffaebf0000-7fffaec60000 rw-p 00000000 00:00 0 7fffaec60000-7fffaec70000 ---p 00000000 00:00 0 7fffaec70000-7fffaece0000 rw-p 00000000 00:00 0 7fffaece0000-7fffaecf0000 ---p 00000000 00:00 0 7fffaecf0000-7fffaed60000 rw-p 00000000 00:00 0 7fffaed60000-7fffaed70000 ---p 00000000 00:00 0 7fffaed70000-7fffaede0000 rw-p 00000000 00:00 0 7fffaede0000-7fffaedf0000 ---p 00000000 00:00 0 7fffaedf0000-7fffaee60000 rw-p 00000000 00:00 0 7fffaee60000-7fffaee70000 ---p 00000000 00:00 0 7fffaee70000-7fffaeee0000 rw-p 00000000 00:00 0 7fffaeee0000-7fffaeef0000 ---p 00000000 00:00 0 7fffaeef0000-7fffaef60000 rw-p 00000000 00:00 0 7fffaef60000-7fffaef70000 ---p 00000000 00:00 0 7fffaef70000-7fffaefe0000 rw-p 00000000 00:00 0 7fffaefe0000-7fffaeff0000 ---p 00000000 00:00 0 7fffaeff0000-7fffaf060000 rw-p 00000000 00:00 0 7fffaf060000-7fffaf070000 ---p 00000000 00:00 0 7fffaf070000-7fffaf0e0000 rw-p 00000000 00:00 0 7fffaf0e0000-7fffaf0f0000 ---p 00000000 00:00 0 7fffaf0f0000-7fffaf160000 rw-p 00000000 00:00 0 7fffaf160000-7fffaf170000 ---p 00000000 00:00 0 7fffaf170000-7fffaf1e0000 rw-p 00000000 00:00 0 7fffaf1e0000-7fffaf1f0000 ---p 00000000 00:00 0 7fffaf1f0000-7fffaf260000 rw-p 00000000 00:00 0 7fffaf260000-7fffaf270000 ---p 00000000 00:00 0 7fffaf270000-7fffaf2e0000 rw-p 00000000 00:00 0 7fffaf2e0000-7fffaf2f0000 ---p 00000000 00:00 0 7fffaf2f0000-7fffaf360000 rw-p 00000000 00:00 0 7fffaf360000-7fffaf370000 ---p 00000000 00:00 0 7fffaf370000-7fffb1570000 rw-p 00000000 00:00 0 7fffb1570000-7fffb1590000 r--p 00000000 fc:06 1615030600 /usr/lib64/libm.so.6 7fffb1590000-7fffb1650000 r-xp 00020000 fc:06 1615030600 /usr/lib64/libm.so.6 7fffb1650000-7fffb16b0000 r--p 000e0000 fc:06 1615030600 /usr/lib64/libm.so.6 7fffb16b0000-7fffb16c0000 r--p 00130000 fc:06 1615030600 /usr/lib64/libm.so.6 7fffb16c0000-7fffb16d0000 rw-p 00140000 fc:06 1615030600 /usr/lib64/libm.so.6 7fffb16d0000-7fffb16e0000 r--p 00000000 fc:06 1615031006 /usr/lib64/libcrypt.so.2.0.0 7fffb16e0000-7fffb1700000 r-xp 00010000 fc:06 1615031006 /usr/lib64/libcrypt.so.2.0.0 7fffb1700000-7fffb1720000 r--p 00030000 fc:06 1615031006 /usr/lib64/libcrypt.so.2.0.0 7fffb1720000-7fffb1730000 r--p 00040000 fc:06 1615031006 /usr/lib64/libcrypt.so.2.0.0 7fffb1730000-7fffb1740000 rw-p 00000000 00:00 0 7fffb1740000-7fffb1750000 r--p 00000000 fc:06 1615031014 /usr/lib64/libgmp.so.10.4.1 7fffb1750000-7fffb17d0000 r-xp 00010000 fc:06 1615031014 /usr/lib64/libgmp.so.10.4.1 7fffb17d0000-7fffb17f0000 r--p 00090000 fc:06 1615031014 /usr/lib64/libgmp.so.10.4.1 7fffb17f0000-7fffb1800000 r--p 000a0000 fc:06 1615031014 /usr/lib64/libgmp.so.10.4.1 7fffb1800000-7fffb1810000 rw-p 000b0000 fc:06 1615031014 /usr/lib64/libgmp.so.10.4.1 7fffb1810000-7fffb1830000 r-xp 00000000 fc:06 1615030899 /usr/lib64/libz.so.1.2.11 7fffb1830000-7fffb1840000 r--p 00010000 fc:06 1615030899 /usr/lib64/libz.so.1.2.11 7fffb1840000-7fffb1850000 rw-p 00020000 fc:06 1615030899 /usr/lib64/libz.so.1.2.11 7fffb1850000-7fffb1890000 r--p 00000000 fc:06 1615030597 /usr/lib64/libc.so.6 7fffb1890000-7fffb1a40000 r-xp 00040000 fc:06 1615030597 /usr/lib64/libc.so.6 7fffb1a40000-7fffb1ab0000 r--p 001f0000 fc:06 1615030597 /usr/lib64/libc.so.6 7fffb1ab0000-7fffb1ac0000 r--p 00250000 fc:06 1615030597 /usr/lib64/libc.so.6 7fffb1ac0000-7fffb1ad0000 rw-p 00260000 fc:06 1615030597 /usr/lib64/libc.so.6 7fffb1ae0000-7fffb1b20000 r--p 00000000 fc:06 1077936030 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3 7fffb1b20000-7fffb1e10000 r-xp 00040000 fc:06 1077936030 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3 7fffb1e10000-7fffb1f20000 r--p 00330000 fc:06 1077936030 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3 7fffb1f20000-7fffb1f30000 ---p 00440000 fc:06 1077936030 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3 7fffb1f30000-7fffb1f40000 r--p 00440000 fc:06 1077936030 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3 7fffb1f40000-7fffb1f50000 rw-p 00450000 fc:06 1077936030 /builddir/build/BUILD/ruby-3.0.3/libruby.so.3.0.3 7fffb1f50000-7fffb1f60000 rw-p 00000000 00:00 0 7fffb1f60000-7fffb1f80000 r--p 00000000 00:00 0 [vvar] 7fffb1f80000-7fffb1f90000 r-xp 00000000 00:00 0 [vdso] 7fffb1f90000-7fffb1fa0000 r--p 00000000 fc:06 1615030592 /usr/lib64/ld64.so.2 7fffb1fa0000-7fffb1ff0000 r-xp 00010000 fc:06 1615030592 /usr/lib64/ld64.so.2 7fffb1ff0000-7fffb2000000 r--p 00060000 fc:06 1615030592 /usr/lib64/ld64.so.2 7fffb2000000-7fffb2010000 r--p 00060000 fc:06 1615030592 /usr/lib64/ld64.so.2 7fffb2010000-7fffb2020000 rw-p 00070000 fc:06 1615030592 /usr/lib64/ld64.so.2 7fffd3830000-7fffd4030000 rw-p 00000000 00:00 0 [stack] test_string.rb . test_struct.rb . test_syntax.rb ............................................................................................................................................................ test_thread.rb ................................................. Fiber count: 10000 (skipping) #1282 test_ractor.rb:1405:in `<top (required)>': workers = (0...8).map do Ractor.new do loop do 10_000.times.map { Object.new } Ractor.yield Time.now end end end 1_000.times { idle_worker, tmp_reporter = Ractor.select(*workers) } "ok" #=> "" (expected "ok") FAIL 1/1489 tests failed make: *** [uncommon.mk:767: yes-btest-ruby] Error 1 ... snip ... ~~~ It reminds me #18117, but that should be fixed, right? -- https://bugs.ruby-lang.org/

1 0

[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