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

[ruby-core:120859] [Ruby master Bug#21108] C-c (SIGINT) crashes ruby when looping Ractors are not taken?
by osyoyu (Daisuke Aritomo) 05 Jun '25

05 Jun '25

Issue #21108 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21108: C-c (SIGINT) crashes ruby when looping Ractors are not taken? https://bugs.ruby-lang.org/issues/21108 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hitting C-c causes ruby to crash under these circumstances. ## Repro Hit C-c while the program is running. ```ruby r1 = Ractor.new do ary = [] loop do Ractor.receive Ractor.yield ary.push(1) end end r2 = Ractor.new(r1) do |r1| loop do |i| r1.send(nil) r1.take end end # r1.take # `take`ing r1 will fix this issue r2.take ``` ### Expected The process quits. ### Actual An `[BUG] unreachable` occurs. The rb_bug() is called inside `ractor_try_yield`. https://github.com/ruby/ruby/blob/ace39a3ed40cc32ff8d48893173413a7e05b8316/… ``` wrap.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. <internal:ractor>:644: [BUG] unreachable ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0022 e:000021 METHOD <internal:ractor>:644 c:0004 p:0014 s:0015 e:000014 BLOCK wrap.rb:5 c:0003 p:0017 s:0012 e:000011 METHOD <internal:kernel>:168 c:0002 p:0008 s:0007 e:000006 BLOCK wrap.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- wrap.rb:3:in 'block in <main>' <internal:kernel>:168:in 'loop' wrap.rb:5:in 'block (2 levels) in <main>' <internal:ractor>:644:in 'yield' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ruby(0x639a516dc55a) [0x639a516dc55a] [0x639a512af8dd] [0x639a512a3a31] [0x639a513876a1] [0x639a513877a6] [0x639a5149b0b3] [0x639a51487565] [0x639a514317db] [0x639a51433e71] [0x639a51434295] ``` See full log at: https://gist.github.com/osyoyu/2ae4fe3e41c139703bab5c321a81dda5 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:117216] [Ruby master Bug#20346] FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take
by forthoney (Seong-Heon Jung) 05 Jun '25

05 Jun '25

Issue #20346 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take https://bugs.ruby-lang.org/issues/20346 * Author: forthoney (Seong-Heon Jung) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior ```ruby require "async" class RactorWrapper def initialize @ractor = Ractor.new do Ractor.recv # Ractor doesn't start until explicitly told to # Do some calculations fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) } fib.call(20) end end def take_async @ractor.send(nil) Thread.new { @ractor.take }.join.value end end Async do |task| 10000.times do |i| task.async do RactorWrapper.new.take_async puts i end end end ``` The above code deadlocks, and when we leave a debugging print statement inside of `Async`'s scheduler's `block` and `unblock` method, we can confirm that we only call `Scheduler.block`, and never `Scheduler.unblock` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120510] [Ruby master Bug#21007] Ractor scheduler issue when multiple threads in a ractor
by luke-gru (Luke Gruber) 05 Jun '25

05 Jun '25

Issue #21007 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21007: Ractor scheduler issue when multiple threads in a ractor https://bugs.ruby-lang.org/issues/21007 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When there are multiple threads in a ractor, these threads can get in a state where they are yielding every 10ms instead of every 100ms. This occurs because in `thread_sched_switch0`, which is called by `thread_sched_switch`, `ruby_thread_set_native` is called. This function calls `rb_ractor_set_current_ec` for the next thread to run, but then when the next thread sets itself up before it runs, it calls `rb_ractor_thread_switch`, but since the ec has already been changed, it never sets back `th->running_time_us` to `0`. The yielding happens every 10ms because a very large value in `th->running_time_us` is always compared to `100ms` so it always yields. This script takes a very long time due to this issue: ```ruby ractors = 5.times.map do |i| Ractor.new(i) do |i0| ts = 4.times.map do Thread.new do counter = 0 while counter < 30_000_000 counter += 1 end end end until ts.none? { |t| t.alive? } $stderr.puts "Ractor #{i0} main thread sleeping" sleep 1 end ts.each(&:join) $stderr.puts "Ractor #{i0} done" end end while ractors.any? r, obj = Ractor.select *ractors ractors.delete(r) end ``` The fix is to set `next_th->running_time_us` back to 0 in `thread_sched_switch0`. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119991] [Ruby master Bug#20905] Ruby VM hangs while using ractors
by ivoanjo (Ivo Anjo) 05 Jun '25

05 Jun '25

Issue #20905 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #20905: Ruby VM hangs while using ractors https://bugs.ruby-lang.org/issues/20905 * Author: ivoanjo (Ivo Anjo) * Status: Open * ruby -v: ruby 3.4.0preview2 (2024-10-07 master 32c733f57b) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hey! While doing some experiments with Ractors I ran into a Ruby VM hang. I see it both on Ruby 3.4.0-preview2 and 3.3.5, but not Ruby 3.2, so this may be related to the M:N scheduling. ### How to reproduce: ``` puts RUBY_DESCRIPTION def counter_loop counter = 0 counter += 1 while counter < 100_000_000 end ractors = 10.times.map { Ractor.new { Thread.new { counter_loop }; counter_loop } } counter_loop ractors.map(&:take) ``` This example never finishes for me. At some point all threads finish work, and the Ruby process will be stuck at 0% cpu. ``` ruby 3.4.0preview2 (2024-10-07 master 32c733f57b) +PRISM [x86_64-linux] warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. ...(hangs)... ``` Reducing the number of ractor seems to make the issue go away, so there may be some timing/thread switching issues involved. Furthermore, all threads seem to be stuck waiting: ``` (gdb) info threads Id Target Id Frame * 1 Thread 0x7836ef0b6c00 (LWP 445418) "ruby" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024bda30) at ./nptl/futex-internal.c:57 2 Thread 0x7836d4800640 (LWP 445419) "ruby" 0x00007836ee725e2e in epoll_wait (epfd=4, events=events@entry=0x7836ef0a8adc <timer_th+28>, maxevents=maxevents@entry=16, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30 3 Thread 0x7836d3fff640 (LWP 445420) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6434) at ./nptl/futex-internal.c:57 4 Thread 0x7836b29ff640 (LWP 445421) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6434) at ./nptl/futex-internal.c:57 5 Thread 0x7836b28fe640 (LWP 445422) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 6 Thread 0x7836b27fd640 (LWP 445423) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 7 Thread 0x7836b26fc640 (LWP 445424) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 8 Thread 0x7836b25fb640 (LWP 445425) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 9 Thread 0x7836b24fa640 (LWP 445426) "rc-example7-2.*" __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 (gdb) thread apply all bt Thread 9 (Thread 0x7836b24fa640 (LWP 445426) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6430, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a40251e800) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 8 (Thread 0x7836b25fb640 (LWP 445425) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6430, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a4025224e0) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 7 (Thread 0x7836b26fc640 (LWP 445424) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6430, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a4025adf00) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 6 (Thread 0x7836b27fd640 (LWP 445423) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6430, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a40263bc20) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 5 (Thread 0x7836b28fe640 (LWP 445422) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6430) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6430, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a40276bc80) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 4 (Thread 0x7836b29ff640 (LWP 445421) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6434) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6434) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6434, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a402729730) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 3 (Thread 0x7836d3fff640 (LWP 445420) "rc-example7-2.*"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024b6434) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024b6434) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024b6434, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024b63d0, cond=0x59a4024b6408) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024b6408, mutex=mutex@entry=0x59a4024b63d0) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eece2e53 in ractor_sched_deq (cr=0x0, vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:1292 #7 nt_start (ptr=0x59a4024bb430) at src/ruby-3.4.0-preview2/thread_pthread.c:2287 #8 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #9 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 2 (Thread 0x7836d4800640 (LWP 445419) "ruby"): #0 0x00007836ee725e2e in epoll_wait (epfd=4, events=events@entry=0x7836ef0a8adc <timer_th+28>, maxevents=maxevents@entry=16, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30 #1 0x00007836eecdca8d in event_wait (vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:2940 #2 timer_thread_polling (vm=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread_mn.c:908 #3 timer_thread_func (ptr=0x59a4024b6330) at src/ruby-3.4.0-preview2/thread_pthread.c:3067 #4 0x00007836ee694ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #5 0x00007836ee726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 1 (Thread 0x7836ef0b6c00 (LWP 445418) "ruby"): #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x59a4024bda30) at ./nptl/futex-internal.c:57 #1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x59a4024bda30) at ./nptl/futex-internal.c:87 #2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x59a4024bda30, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 #3 0x00007836ee693a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x59a4024bdb80, cond=0x59a4024bda08) at ./nptl/pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=cond@entry=0x59a4024bda08, mutex=mutex@entry=0x59a4024bdb80) at ./nptl/pthread_cond_wait.c:627 #5 0x00007836eecd77dd in rb_native_cond_wait (cond=cond@entry=0x59a4024bda08, mutex=mutex@entry=0x59a4024bdb80) at src/ruby-3.4.0-preview2/thread_pthread.c:222 #6 0x00007836eecd90d9 in thread_sched_wait_running_turn (sched=sched@entry=0x59a4024bdb80, th=0x59a4024b88c0, can_direct_transfer=can_direct_transfer@entry=false) at src/ruby-3.4.0-preview2/thread_pthread.c:863 #7 0x00007836eecd9f4a in rb_ractor_sched_sleep (ec=ec@entry=0x59a4024bdd20, cr=cr@entry=0x59a4024bda60, ubf=ubf@entry=0x7836eec341f0 <ractor_sleep_interrupt>) at src/ruby-3.4.0-preview2/thread_pthread.c:1349 #8 0x00007836eec34de6 in ractor_sleep_with_cleanup (cf_data=0x7ffcaa1e7640, cf_func=0x7836eec35b70 <ractor_wait_take_cleanup>, wait_status=wait_taking, cr=0x59a4024bda60, ec=0x59a4024bdd20) at ractor.c:691 #9 ractor_wait_take (take_basket=0x7ffcaa1e7650, r=0x59a4027851d0, cr=0x59a4024bda60, ec=0x59a4024bdd20) at ractor.c:1220 #10 ractor_take (r=0x59a4027851d0, ec=0x59a4024bdd20) at ractor.c:1241 #11 builtin_inline_class_711 (ec=0x59a4024bdd20, self=<optimised out>) at src/ruby-3.4.0-preview2/ractor.rb:712 #12 0x00007836eed30fe7 in invoke_bf (argv=<optimised out>, bf=<optimised out>, reg_cfp=<optimised out>, ec=<optimised out>) at src/ruby-3.4.0-preview2/vm_insnhelper.c:7330 #13 vm_invoke_builtin_delegate (cfp=<optimised out>, bf=<optimised out>, cfp=<optimised out>, bf=<optimised out>, start_index=<optimised out>, ec=<optimised out>) at src/ruby-3.4.0-preview2/vm_insnhelper.c:7353 #14 vm_invoke_builtin_delegate (start_index=<optimised out>, bf=<optimised out>, cfp=<optimised out>, ec=<optimised out>) at src/ruby-3.4.0-preview2/vm_insnhelper.c:7342 #15 vm_exec_core (ec=0x59a4024bdd20) at src/ruby-3.4.0-preview2/insns.def:1632 #16 0x00007836eed34c1a in rb_vm_exec (ec=0x59a4024bdd20) at vm.c:2564 #17 0x00007836eed3b222 in vm_call0_cc (ec=0x59a4024bdd20, recv=132176890167200, id=<optimised out>, argc=<optimised out>, argv=<optimised out>, cc=<optimised out>, kw_splat=0) at src/ruby-3.4.0-preview2/vm_eval.c:101 #18 0x00007836eed3d9e4 in rb_call0 (ec=0x59a4024bdd20, recv=132176890167200, mid=6081, argc=0, argv=<optimised out>, call_scope=<optimised out>, self=132177315121880) at src/ruby-3.4.0-preview2/vm_eval.c:554 #19 0x00007836eed3e6f6 in rb_call (scope=<optimised out>, argv=0x7ffcaa1e7b40, argc=0, mid=6081, recv=132176890167200) at src/ruby-3.4.0-preview2/vm_eval.c:873 #20 rb_funcall_with_block_kw (recv=132176890167200, mid=6081, argc=0, argv=0x7ffcaa1e7b40, passed_procval=4, kw_splat=<optimised out>) at src/ruby-3.4.0-preview2/vm_eval.c:1192 #21 0x00007836eed39e38 in vm_yield_with_cref (is_lambda=0, cref=0x0, kw_splat=0, argv=0x7ffcaa1e7b38, argc=1, ec=<optimised out>) at vm.c:1646 #22 vm_yield (kw_splat=0, argv=0x7ffcaa1e7b38, argc=1, ec=<optimised out>) at vm.c:1654 #23 rb_yield_0 (argv=0x7ffcaa1e7b38, argc=1) at src/ruby-3.4.0-preview2/vm_eval.c:1344 #24 rb_yield (val=<optimised out>) at src/ruby-3.4.0-preview2/vm_eval.c:1360 #25 0x00007836eea68efc in rb_ary_collect (ary=132177315121880) at array.c:3714 #26 0x00007836eed1b03c in vm_call_cfunc_with_frame_ (stack_bottom=<optimised out>, argv=<optimised out>, argc=0, calling=<optimised out>, reg_cfp=0x7836edffefa0, ec=0x59a4024bdd20) at src/ruby-3.4.0-preview2/vm_insnhelper.c:3788 #27 vm_call_cfunc_with_frame (ec=0x59a4024bdd20, reg_cfp=0x7836edffefa0, calling=<optimised out>) at src/ruby-3.4.0-preview2/vm_insnhelper.c:3834 #28 0x00007836eed217f0 in vm_sendish (ec=0x59a4024bdd20, reg_cfp=0x7836edffefa0, cd=0x59a4027833f0, block_handler=<optimised out>, method_explorer=mexp_search_method) at src/ruby-3.4.0-preview2/vm_callinfo.h:415 #29 0x00007836eed2edd1 in vm_exec_core (ec=0x59a4024bdd20) at src/ruby-3.4.0-preview2/insns.def:851 #30 0x00007836eed34c1a in rb_vm_exec (ec=0x59a4024bdd20) at vm.c:2564 #31 0x00007836eed46e8b in rb_iseq_eval_main (iseq=iseq@entry=0x7836edea70f8) at vm.c:2830 #32 0x00007836eeb3d895 in rb_ec_exec_node (ec=ec@entry=0x59a4024bdd20, n=n@entry=0x7836edea70f8) at eval.c:281 #33 0x00007836eeb4140b in ruby_run_node (n=0x7836edea70f8) at eval.c:319 #34 0x000059a400cd1187 in rb_main (argv=0x7ffcaa1e8118, argc=2) at ./main.c:43 #35 main (argc=<optimised out>, argv=<optimised out>) at ./main.c:62 ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:122305] [Ruby Bug#21376] Inconsistent equality between Sets with different compare_by_identity, different classes
by Ethan (Ethan -) 05 Jun '25

05 Jun '25

Issue #21376 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21376: Inconsistent equality between Sets with different compare_by_identity, different classes https://bugs.ruby-lang.org/issues/21376 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This is an inconsistency between the new core Set and the ruby-implemented Set. I think probably the new implementation's behavior seems correct and the ruby implementation is an incorrect edge case. ```ruby class MySet < Set end o = Object.new Set.new([o]).compare_by_identity == MySet.new([o]) # => false on 3.5.0; true with the ruby implementation ``` My understanding is that, for Hash, if two hashes have unequal `compare_by_identity?` they are never equal (even if containing identical contents), unless both are empty. It would make sense for Set to be the same. Hmm, analyzing the ruby Set#== a bit more, I see a further edge case where a non-identity set is considered equal to an identity set with as few as one element in common. ```ruby set_by_eq = Set.new(['a', 'b', 'c']) # => #<Set: {"a", "b", "c"}> set_by_id = MySet.new.compare_by_identity.merge(['a', 'a'.dup, 'a'.dup]) # => #<MySet: {"a", "a", "a"}> set_by_eq == set_by_id # => true in the ruby set, false in core set set_by_id == set_by_eq # => false in both ``` The latter seems unlikely it would ever be triggered unintentionally. The former I did happen across, but since I think the new behavior is correct, I will not be affected when I fix my code to consistently compare_by_identity. Given that, it may be questionable whether it's worth fixing. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122338] [Ruby Bug#21384] const_added is triggered twice when using autoload
by petekinnecom (Pete Kinnecom) 05 Jun '25

05 Jun '25

Issue #21384 has been reported by petekinnecom (Pete Kinnecom). ---------------------------------------- Bug #21384: const_added is triggered twice when using autoload https://bugs.ruby-lang.org/issues/21384 * Author: petekinnecom (Pete Kinnecom) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As the title says, I've noticed that `const_added` is invoked twice when using `autoload`. I'm wondering if this behavior is intended or perhaps a bug. Here's a small script to reproduce what I'm seeing: ``` ruby require "tmpdir" dir = Dir.mktmpdir File.write( File.join(dir, "const.rb"), "class Const; end" ) def Object.const_added(const_name) super.tap { puts "const_added: #{const_name}" } end $LOAD_PATH << dir puts "before autoload call" autoload :Const, "const" puts "after autoload call" puts Const # Produces output: # # => before autoload call # => const_added: Const # => after autoload call # => const_added: Const # => Const ``` I'm seeing the behavior using the following docker containers ruby:3.2 and ruby:3.5-rc when running like so: `docker run -v ./:/home ruby:3.5-rc ruby /home/script.rb`. Thanks. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121142] [Ruby master Misc#21154] Document or change Module#autoload?
by fxn (Xavier Noria) 05 Jun '25

05 Jun '25

Issue #21154 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21154: Document or change Module#autoload? https://bugs.ruby-lang.org/issues/21154 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- The documentation of `Module#autoload?` says > Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors. Cool, but in the following snippet ```ruby autoload :Foo, 'foo' autoload?(:Foo) ``` the second line could evaluate to `nil`, and this does not seem to agree. I just registered an autoload, therefore (according to the documentation) I should get "foo" back in line 2. I'd like to ask for clarification from the Ruby team: 1. Is the documentation complete? Should that second line always return "foo"? 2. If the answer is no, which is the logic missing in the docs? Thank you! -- https://bugs.ruby-lang.org/

3 31

[ruby-core:122164] [Ruby Feature#21347] Add `open_timeout` as an overall timeout option for `Socket.tcp`
by shioimm (Misaki Shioi) 05 Jun '25

05 Jun '25

Issue #21347 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #21347: Add `open_timeout` as an overall timeout option for `Socket.tcp` https://bugs.ruby-lang.org/issues/21347 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- I propose to add an overall timeout option to `Socket.tcp` (and `TCPSocket.new`) ### Background Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options: - `resolv_timeout`, which controls the timeout for DNS resolution - `connect_timeout`, which controls the timeout for the connection attempt With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized. As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap. Example: When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set: 1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved). 2. A connection attempt is initiated to the IPv6 address 3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues. 4. After 200ms from the start, the method raises a `resolv_timeout` error. In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms). Furthermore, in HEv2, connection attempts are also parallelized. It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted. Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured. Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout. Example: When `connect_timeout: 100ms` is set and 3 address candidates: 1. Connect to address `a` at t=0ms. 2. Connect to address `b` at t=250ms. 3. Connect to address `c` at t=500ms. 4. If all fail, the exception is raised at t=1500ms (1000ms after `c`, 1250ms after `b`, 1500ms after `a`). 1. Start a connection attempt to the address `a` 2. 250ms after step 1, start a new connection attempt to the address `b` 3. 500ms after step 1, start a new connection attempt to the address `c` 4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about. These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout. ### Proposal I propose adding an `open_timeout` option to `Socket.tcp` in the following PR, which triggers a timeout after a specified duration has elapsed from the start of the method. https://github.com/ruby/ruby/pull/13368 The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`. If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases. If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`. While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout. ### Outcome If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`. https://github.com/ruby/ruby/blob/aa0f689bf45352c4a592e7f1a044912c40435266/… -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122228] [Ruby Feature#21359] Introduce `Exception#cause=` for Post-Initialization Assignment
by ioquatix (Samuel Williams) 05 Jun '25

05 Jun '25

Issue #21359 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #21359: Introduce `Exception#cause=` for Post-Initialization Assignment https://bugs.ruby-lang.org/issues/21359 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- Ruby currently allows an exception’s `cause` to be explicitly set **only at the time of raising** using `raise ..., cause: ...`. However, there are valid use cases where it would be convenient to set the cause when creating an exception. ## The Problem Ruby supports exception chaining via the `cause:` keyword during a `raise`, like so: ```ruby raise StandardError.new("failure"), cause: original_exception ``` ## Proposed Solution Introduce `Exception#cause=` as a public setter method on `Exception`, allowing post-initialization assignment of the cause: ```ruby cause = RuntimeError.new("low-level error") error = StandardError.new("higher-level error") error.cause = cause ``` It would be semantically equivalent to the following implementation: ```ruby error = StandardError.new("error") cause = RuntimeError.new("cause") class Exception def cause= value backtrace = self.backtrace_locations raise self, cause: value rescue Exception self.set_backtrace(backtrace) end end p error.cause # nil error.cause = cause p error.cause # => #<RuntimeError: cause> ``` ### Benefits * Simplifies creation of rich exception objects in frameworks, tools, and tests. * Enables structured error chaining in asynchronous and deferred execution environments. * Avoids misuse of `raise`/`rescue` for control flow and metadata setting. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:121700] [Ruby Feature#21279] Bare "rescue" should not rescue NameError
by AMomchilov (Alexander Momchilov) 05 Jun '25

05 Jun '25

Issue #21279 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #21279: Bare "rescue" should not rescue NameError https://bugs.ruby-lang.org/issues/21279 * Author: AMomchilov (Alexander Momchilov) * Status: Open ---------------------------------------- # Abstract Bare `rescue` keywords (either as a modifier like `foo rescue bar` or as clause of a `begin` block) should _not_ rescue `NameError` or `NoMethodError`. This behaviour is unexpected and hides bugs. ## Background Many Rubyists are surprised to learn that [`NameError`](https://docs.ruby-lang.org/en/master/NameError.html) is a subclass of [`StandardError`](https://docs.ruby-lang.org/en/master/StandardError.html), so it's caught whenever you use a "bare" `rescue` block. ```ruby begin DoesNotExist rescue => e p e # => #<NameError: uninitialized constant DoesNotExist> end ``` Similarly, [`NoMethodError`](https://docs.ruby-lang.org/en/master/NoMethodError.html) is also rescued, because it's a subclass of `NameError`. ```ruby begin does_not_exist() rescue => e p e # => #<NoMethodError: undefined method `does_not_exist' for main> end ``` This is almost never expected behaviour. `NameError`/`NoMethodError` is usually the result of a typo in the Ruby source, that cannot be reasonably recovered from at runtime. It's a programming error just like a [`SyntaxError`](https://docs.ruby-lang.org/en/master/SyntaxError.html), which _isn't_ a `StandandError`. ## Proposal No matter the solution, solving this problem will require a breaking change. Perhaps this could be part of Ruby 4? The most obvious solution is to change the superclass of `NameError` from `StandardError` to `Exception` (or perhaps [`ScriptError`](https://docs.ruby-lang.org/en/master/ScriptError.html), similar to `SyntaxError`). ### Alternatives considered If we want to avoid changing the inheritance hierarchy of standard library classes, we could instead change the semantics of bare `rescue` from "rescues any subtype of `StandardError`", to instead be "rescues any subtype of `StandardError` except `NameError` or its subtypes". This is worse in my opinion, as it complicates the semantics for no good reason. ## Use cases <details><summary>fun example</summary> The worst case I've seen of this came from a unit tesat like so: ```ruby test "aborts if create_user returns error" do mock_user_action(data: { user: { id: 123, ... }, errors: [{ code: "foo123" }] }) ex = assert_raises(StandardError) do CreateUser.perform(123) end assert_match(/foo123/, ex.message) end ``` This test passes, but not for the expected reason. It turns out that inside of the business logic of `CreateUser`, the error code data was accessed as a method call like `error.code`, rather than a key like `error[:code]`. This lead to: ``` NoMethodError (undefined method `code' for {:code=>"foo123"}:Hash) ``` The `NoMethodError` is a `StandardError`, and even more insidious, because `foo123` is part of the NoMethodError's default message, the `assert_match(/foo123/, ex.message)` also mathches! The correct fix here would be to introduce a specific error like `UserCreationError` that can be rescued specifically, with a field like `code` that can be matched instead of the message. Regardless, this illustrates the kind of confusion that comes from `NoMethodError` being a `StandardError`. </details> # Discussion It might be useful to distinguish between `NameError`s made in "static" code like `DoesNotExist` or `does_not_exist()`, versus those encountered dynamically via `Object.const_get(dynamic_value)` or `object.send(dynamic_value)`. In those metaprogramming cases, the error could be a consequence of bad runtime data, which is more recoverable than just some fundamental error with your Ruby code. -- https://bugs.ruby-lang.org/

8 8