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

[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:122414] [Ruby Bug#21397] `snap run ruby.gem` fails when both snap and deb package are installed
by mk76835897 (Max Kapur) 06 Jun '25

06 Jun '25

Issue #21397 has been reported by mk76835897 (Max Kapur). ---------------------------------------- Bug #21397: `snap run ruby.gem` fails when both snap and deb package are installed https://bugs.ruby-lang.org/issues/21397 * Author: mk76835897 (Max Kapur) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- There appears to be a packaging issue with the [official](https://www.ruby-lang.org/en/news/2018/11/08/snap/) Ruby snap. On a clean virtual machine running Ubuntu 24.04, the `gem` command fails when run from the snap if the Ruby deb package is also present: ``` $ sudo apt update -y $ sudo apt upgrade -y $ sudo apt install ruby-full -y $ sudo snap install --classic ruby $ snap run ruby.gem -v ruby: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE ``` The error does not occur unless the deb package is installed. However, installing the snap alongside the deb is not unusual, as many Ubuntu images (such as the GitHub Actions runners) have Ruby v3.3 preinstalled as a deb by default. Installing the snap is an easy way to get Ruby v3.4 (without compiling it from source). Additional info: ``` $ snap version snap 2.68.4 snapd 2.68.4 series 16 ubuntu 24.04 kernel 6.8.0-45-generic $ ruby -v ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu] $ snap run ruby -v ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] ``` - I previously reported this bug on GitHub: https://github.com/ruby/snap.ruby/issues/42 - I also consulted the Snapcraft page, but it just says to report bugs to info(a)ruby-gems.org: https://snapcraft.io/ruby -- https://bugs.ruby-lang.org/

2 1

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

06 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:122471] [Ruby Feature#15854] Tracing instance variable assignment
by st0012 (Stan Lo) 06 Jun '25

06 Jun '25

Issue #15854 has been updated by st0012 (Stan Lo). > I think tracing ivar assignments would be prohibitively slow, and so probably not really usable in practice. Since TracePoint is only recommended for debugging use, I think trading execution speed for more efficient debugging experience is a worth tradeoff for many people (myself included). Currently, tools like `debug` watch events like `call` and `return` to inspect instance variable changes ([example](https://github.com/ruby/debug/blob/master/lib/debug/breakpoint.rb#…) or even line event like the description gives, which are all much slower than having a dedicated ivar set event. Anyway, I made a PR to support it here: https://github.com/ruby/ruby/pull/13369 ---------------------------------------- Feature #15854: Tracing instance variable assignment https://bugs.ruby-lang.org/issues/15854#change-113659 * Author: igaiga (Kuniaki Igarashi) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- I suggest a feature "tracing instance variable assignment". It's useful for debugging. Use case: In Rails, we use instance variables in views and controllers. When we got a bug caused by instance variable unintentional values, if we traced instance variable assignment timing, it would be good informations. And in Rails views, there are no source codes of self class. That's built dynamically. Current behavior (Ruby2.6): In Ruby 2.6, only if there is a source code file to assign instance variable, we can trace instance variable assignment by following code (check_instance_variable_assignment.rb). But it's difficult if the assignment codes are defined dynamically. For example, in Rails view. (And in another story, global variables assignment are traced by Kernel#trace_var.) check_instance_variable_assignment.rb ```ruby def trace_start TracePoint.trace(:line) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" line = File.open(tp.path, "r"){|f| f.readlines[tp.lineno - 1] } node = RubyVM::AbstractSyntaxTree.parse(line).children.last # check instance variable assignment next unless node.type == :IASGN # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name instance_variable_name = node.children.first next unless instance_variable_name == target_instance_variable_name.to_sym puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.defined_class} #{tp.method_id}" end end class Foo def bar @bar = "text" end end trace_start Foo.new.bar #=> Foo @bar is assigned in check_instance_variable_assignment.rb:25 Foo bar ``` Suggesting feature example: Add new arguments for TracePoint.new method like :line and :call to trace instance variables assignment. - :iasgn (IASGN name from RubyVM::AbstractSyntaxTree::Node) - :casgn (CVASGN (or CASGN?) name from RubyVM::AbstractSyntaxTree::Node. I think class variables tracing is useful too.) And get informations - class name (It might be get by trace_point.self) - variable name ("@foo", "@@foo") A sample code to use the feature: tp_iasgn.rb ```ruby TracePoint.trace(:iasgn) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name next unless target_instance_variable_name == tp.variable_name puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.method_id} #{tp.defined_class}" puts caller # even in dynamic code case, we can get caller informations. end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122468] [Ruby Bug#17516] forking in a ractor causes Ruby to crash
by jhawthorn (John Hawthorn) 06 Jun '25

06 Jun '25

Issue #17516 has been updated by jhawthorn (John Hawthorn). Right now forking with a block or forking and execing works without crashing ``` ./miniruby -e 'Ractor.new { fork(){} }.take' ``` However as described in the issue forking with no block still crashes. ``` ./miniruby -e 'Ractor.new { fork() }.take' -e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. -e:1: warning: Ractor#take was deprecated and use Ractor#value instead. This method will be removed after the end of Aug 2025 [BUG] rb_thread_terminate_all: called by child thread (0x0000000000000000, 0x00005949b17c44e0) ruby 3.5.0dev (2025-06-05T18:01:41Z master 3e626a6aed) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ``` ---------------------------------------- Bug #17516: forking in a ractor causes Ruby to crash https://bugs.ruby-lang.org/issues/17516#change-113656 * Author: pkmuldoon (Phil Muldoon) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I just want to point out, there's absolutely no reason to do this, but r = Ractor.new do Process.fork() end Will cause: <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [BUG] rb_thread_terminate_all: called by child thread (0x0000700004ddca40, 0x00007f981b567ee0) ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] -- Crash Report log information -------------------------------------------- See Crash Report log file under the one of following: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- C level backtrace information ------------------------------------------- => #<Ractor:#3 (pry):5 terminated> [4] pry(main)> /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_vm_bugreport+0x6cf) [0x103084d1f] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug_without_die+0x206) [0x102e9e2b6] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug+0x71) [0x103091e6b] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_thread_terminate_all+0x329) [0x10301e5b9] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ractor_terminate_all+0xa3) [0x102f8acc3] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ec_cleanup+0x229) [0x102ea9299] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(ruby_stop+0x9) [0x102ea9509] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_2+0x8ce) [0x103027fce] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_1+0x10d) [0x10302753d] /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff20382950] ---Files-------------------------------- ruby_2021-01-06-104315_phillip-muldoon-FA588.crash (31.8 KB) -- https://bugs.ruby-lang.org/

1 0

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

06 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) 06 Jun '25

06 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:122356] [Ruby Feature#21390] Deprecate passing arguments to Set#to_set and Enumerable#to_set
by jeremyevans0 (Jeremy Evans) 06 Jun '25

06 Jun '25

Issue #21390 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21390: Deprecate passing arguments to Set#to_set and Enumerable#to_set https://bugs.ruby-lang.org/issues/21390 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Array#to_a, Hash#to_h, Enumerable#to_a, and Enumerable#to_h do not allow you to specify subclasses. This has undesired behavior when passing non-Set subclasses. All of these are currently allowed, and none make sense: ```ruby enum = [1,2,3].to_enum enum.to_set(Hash) enum.to_set(Struct.new("A", :a)) enum.to_set(ArgumentError) enum.to_set(Thread){} ``` Users who want to create instances of a subclass of Set from an enumerable should pass the enumerable to SetSubclass.new instead of using to_set, similar to how they would have to handle subclasses of Array or Hash. I've submitted a pull request that implements this: https://github.com/ruby/ruby/pull/13489 With the pull request, block arguments are still allowed (no warning). Positional and keyword argument use results in a deprecation warning. I would like to deprecate this in Ruby 3.5 (next feature release), and remove it in Ruby 3.6 (following feature release). -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122458] [Ruby Bug#21400] rb_bug() hit when killing current root fiber on non-main thread
by luke-gru (Luke Gruber) 06 Jun '25

06 Jun '25

Issue #21400 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21400: rb_bug() hit when killing current root fiber on non-main thread https://bugs.ruby-lang.org/issues/21400 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.5.0dev * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This following code hits an `rb_bug`: ```ruby Thread.new { Fiber.current.kill }.join ``` Normally fibers gracefully handle this case by terminating and switching to another fiber, but if there is no other fiber it raises the `FIBER_FATAL_FIBER_KILLED` error and this is not caught by the starting thread, resulting in a bug. -- https://bugs.ruby-lang.org/

1 1

[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