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

[ruby-core:121861] [Ruby Bug#21312] ruby 3.5-dev installs a gemspec for rdoc that misses dependencies
by deivid 06 Jun '25

06 Jun '25

Issue #21312 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #21312: ruby 3.5-dev installs a gemspec for rdoc that misses dependencies https://bugs.ruby-lang.org/issues/21312 * Author: deivid (David Rodríguez) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Similarly to https://bugs.ruby-lang.org/issues/20581, installing ruby 3.5-dev installs a gemspec for rdoc that it's missing its own dependency on psych. This causes issues when using Bundler, as reported at https://github.com/rubygems/rubygems/issues/8637. I created a workaround in Bundler to behave better under this situation and print a warning rather than creating an incorrect lockfile, but ruby installer should fix this too. Thank you! -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121601] [Ruby Feature#21258] Retire CGI library from Ruby 3.5
by hsbt (Hiroshi SHIBATA) 06 Jun '25

06 Jun '25

Issue #21258 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21258: Retire CGI library from Ruby 3.5 https://bugs.ruby-lang.org/issues/21258 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I would like to retire CGI library from Ruby 3.5.0 release. It means CGI is not promoted bundled gems. The users need to run `gem install cgi` after Ruby 3.5 if they want to use CGI library. ## Background I handled two CVEs related CGI library at https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/ We shouldn't spend our time to maintain CGI library in the future because CGI is old protocol. In fact, Perl 5.22.0 removed CGI.pm at 2015, Python 3.13 also removed cgi at Nov 2024. ## Problem CGI is not using widely today. But `cgi/escape` is core feature in Ruby ecosystem. `erb`, `net-http` and `bundler` depend `CGI.escape`/`CGI.unescape`. And `CGI.escapeHTML`, `CGI.escapeURIComponent` are used at that libraries. ## Solution 1. We keep only `cgi/escape` feature in Ruby. The current CGI library is removed and depend `cgi-escape` gem. 2. We migrate `cgi/escape` to other class/module. The current CGI library and `cgi/escape` are removed. The new class/module location is diffcult. I discussed that with some Ruby core member. * `URI.escape/unescape`: `URI.escape` is migrated to `URI::RFC2396_PARSER.escape` at Ruby 3.4. The new `URI.escape` is confusing name with historical reason. * `URI::Util.escape`: It seems okay...? I think URI or related name are good place for that because other language provide that under the url libraries: Python: ``` import urllib.parse urllib.parse.quote() ``` Java: ``` import java.net.URLEncoder; URLEncoder.encode() ``` Go: ``` import "net/url" url.QueryEscape() ``` ## Migration plan If Idea 2 is accepted and decide new location, We provide dummy module and method for `cgi/escape`. That dummy module call new method and warn about deprecating `cgi/escape`. -- https://bugs.ruby-lang.org/

8 10

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

[ruby-core:122221] [Ruby Feature#21358] Advanced filtering support for #dig
by lovro-bikic 05 Jun '25

05 Jun '25

Issue #21358 has been reported by lovro-bikic (Lovro Bikić). ---------------------------------------- Feature #21358: Advanced filtering support for #dig https://bugs.ruby-lang.org/issues/21358 * Author: lovro-bikic (Lovro Bikić) * Status: Open ---------------------------------------- Currently, `#dig` can be used to access nested data structures using "simple" keys, such as array indices or hash keys. Real-world applications sometimes require non-trivial data access, for example, finding an item in an array based on some criteria, then returning some property of that item. This feature request is to add support for such non-trivial access to `#dig`, concretely by allowing `Proc`s as dig keys. ## Introductory example Given the following data structure (similar to one from [dig docs](https://docs.ruby-lang.org/en/3.4/dig_methods_rdoc.html)) ```ruby item = { id: '0001', batters: { batter: [ { id: '1001', type: 'Regular' }, { id: '1002', type: 'Chocolate' }, { id: '1003', type: 'Blueberry' }, { id: '1004', type: 'Devils Food' } ] } } ``` and the requirement "find ID of batter with type 'Chocolate'" (assuming we don't know its position in the array), currently the datum can be retrieved like so: ```ruby item.dig(:batters, :batter)&.find { it[:type] == 'Chocolate' }&.[](:id) # => "1002" ``` If `#dig` supported `Proc` as keys, the solution could be: ```ruby item.dig(:batters, :batter, -> { it[:type] == 'Chocolate' }, :id) # => "1002" ``` ## Implementation Here's a monkey patch which adds `Proc` support to `Array#dig`, to play around with: ```ruby class Array alias_method :original_dig, :dig def dig(key, *identifiers) case key when Proc val = find(&key) identifiers.any? ? val&.dig(*identifiers) : val else original_dig(key, *identifiers) end end end ``` This code also shows how I would define `Proc` argument behavior for arrays. The proc is called with each array item, and the *first* one for which a truthy value is evaluated is returned. ## Precedence I see this feature similar to [JSONPath's filter selector](https://www.rfc-editor.org/rfc/rfc9535.html#name-filter-selector), where the [equivalent path](https://jsonpath.com/#eJx1jlFrwjAQx79KOAQnlFKnPliQjTn2LHs1PsT2rIEs0eQ… for the introductory example would be: ``` $.batters.batter[?(@.type == 'Chocolate')].id ``` I am not familiar with similar implementations in other programming languages, so I cannot draw parallels there. ## Real-world examples Here's a [GitHub code search](https://github.com/search?q=%2F(%5Cw%5C%5B%5Cw%2B%3F%5C%5D%7C%5C.(f… with potential candidates that could be refactored with this new feature. There are some false positives on this link, sorry about that. The regex is also probably incomplete, so there could be more results. I will highlight two examples from the results and how they could be refactored: ```ruby # https://github.com/moraki-finance/ruby-experian/blob/84f7def9987b6377f4718a… value_section&.find { |d| d["Tipo"] == value_name }&.dig("ListaValores", "Valor")&.find { |v| v["Periodo"] == period.to_s }&.dig("Individual")&.to_i value_section&.dig(-> { it["Tipo"] == value_name }, "ListaValores", "Valor", -> { it["Periodo"] == period.to_s }, "Individual")&.to_i # https://github.com/cyfronet-fid/marketplace/blob/f84947777aa79d02fb98709241… datasource_data&.dig("identifiers", "alternativeIdentifiers")&.find { |id| id["type"] == "PID" }&.[]("value") datasource_data&.dig("identifiers", "alternativeIdentifiers", -> { it["type"] == "PID" }, "value") ``` ## Final thoughts The main benefit of this feature would be to not have to insert other methods in-between `#dig`, for example `#find` in the above examples. This could lead to cleaner code when handling complex data structures (such as returned from JSON APIs), with fewer usages of safe navigation. On the other hand, `Proc` argument could be misinterpreted by developers to mean something else (e.g. return _all_ items for which the proc returns a truthy value). `Proc` arguments could also be seen as non-idiomatic Ruby. It should also be clearly defined how many results such `dig`s return, just the first one for which the Proc is truthy (`#find` behavior), or all for which it's truthy (`#select` behavior). I admit at this point I'm not entirely sure, though I'm leaning towards the former (`#find`). Final note: in this feature request I considered only `Array#dig`, but `Hash#dig` could be considered as well (the proc receives each key/value pair). -- https://bugs.ruby-lang.org/

3 2