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

[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

[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:121973] [Ruby Bug#21322] Namespaces and builtin classes as arguments and return values
by fxn (Xavier Noria) 13 May '25

13 May '25

Issue #21322 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21322: Namespaces and builtin classes as arguments and return values https://bugs.ruby-lang.org/issues/21322 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- @tagomoris thanks for the docs under `doc/namespace.md`. Unless I missed it, I believe there is an edge case related to builtin classes (using the vocabulary there). Consider: ```ruby # test.rb ns = Namespace.new ns.require_relative 'foo' X = 1 ns::C.x(Object) # foo.rb class C def self.x(obj) obj::X end end ``` `obj::X` raises. I believe this is consistent with the feature, but maybe would deserve docs, because from the point of view of the Ruby programmer I am passing an object, no constant name resolution is happening in `foo.rb`. See what I mean? I believe, from my tests, that something analogous happens if `ns::C.x` returns (the namespaced) `Object`. In the main namespace, you don't get the object passed up as-is. I am also curious about how is this implemented (maybe to comment here, not necessarily in the docs). -- https://bugs.ruby-lang.org/

2 7