September 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125706] [Ruby Bug#22106] Getting a segfault when using finalizers and/or WeakMap in Ractors
by miles-georgi (Miles Georgi) 08 Sep '26

08 Sep '26

Issue #22106 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22106: Getting a segfault when using finalizers and/or WeakMap in Ractors https://bugs.ruby-lang.org/issues/22106 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- If I run the following script I get a segfault: ```ruby def ractor_and_port_counts total_ractor_count = total_ractor_port_count = open_ractor_count = open_ractor_port_count = 0 ObjectSpace.each_object do |object| case object when Ractor total_ractor_count += 1 open_ractor_count += 1 unless object.default_port.closed? when Ractor::Port total_ractor_port_count += 1 open_ractor_port_count += 1 unless object.closed? end end [total_ractor_count, open_ractor_count, total_ractor_port_count, open_ractor_port_count] end def show_ractor_counts GC.start pp ractor_and_port_counts end class Wrapper class << self def finalizer_proc proc do |id| wrapper_to_ractor = Ractor[:wrapper_to_ractor] if wrapper_to_ractor wrapper_to_ractor[id]&.each_key { |ractor| ractor << :close } rescue Ractor::ClosedError end end end def setup_finalizer(wrapper) wrapper_to_ractor = Ractor[:wrapper_to_ractor] ||= {} map = wrapper_to_ractor[wrapper.object_id] ||= ObjectSpace::WeakMap.new map[wrapper.ractor] = true ObjectSpace.define_finalizer(wrapper, &finalizer_proc) end end attr_reader :ractor def initialize(object) @ractor = Ractor.new do loop { break if receive == :close } o = nil end @ractor.send(object, move: true) self.class.setup_finalizer(self) end end class Outer def initialize = @inner = Wrapper.new(Inner.new) end class Inner; end show_ractor_counts outer = Wrapper.new(Outer.new) show_ractor_counts outer = nil # Removing the following line makes it so it only segfaults sometimes instead of everytime show_ractor_counts ``` I'll attach the script and the whole segfault but part of the segfault is: ``` <internal:gc>:44: [BUG] FL_FINALIZE flag is set, but finalizers are not found ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0010 s:0023 e:000018 l:y b:0001 METHOD <internal:gc>:44 c:0003 p:0004 s:0011 e:000010 l:y b:0001 METHOD test_scripts/finalizer-in-ractor-test-segfault:23 c:0002 p:0075 s:0007 E:000f98 l:n b:---- EVAL test_scripts/finalizer-in-ractor-test-segfault:72 [FINISH] c:0001 p:0000 s:0003 E:000b40 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test_scripts/finalizer-in-ractor-test-segfault:72:in '<main>' test_scripts/finalizer-in-ractor-test-segfault:23:in 'show_ractor_counts' <internal:gc>:44:in 'start' ``` This happens in both a local build of 4.1-dev and 4.0.5 I suspect one might need to put GC.start at the end of the script if unable to reproduce. ---Files-------------------------------- segfault.txt (22 KB) finalizer-in-ractor-test-segfault (1.66 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126572] [Ruby Bug#22293] `String#unicode_normalize` does not work in non-main Ractor
by nobu (Nobuyoshi Nakada) 08 Sep '26

08 Sep '26

Issue #22293 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22293: `String#unicode_normalize` does not work in non-main Ractor https://bugs.ruby-lang.org/issues/22293 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This fails consistently since Ruby 3.0 (except for using `#take` instead of `#value`). ```console $ ruby -v -W:no-ex -e 'p Ractor.new{"aaa".unicode_normalize}.value' ruby 4.1.0dev (2026-09-04T13:17:34Z master 3643154e6d) +PRISM [arm64-darwin25] #<Thread:0x0000000123bf0008 run> terminated with exception (report_on_exception is true): /opt/local/lib/ruby/4.1.0+4/unicode_normalize/normalize.rb:138:in 'UnicodeNormalize.normalize': can not access non-shareable objects in constant UnicodeNormalize::NF_HASH_C by non-main ractor. (Ractor::IsolationError) from -e:1:in 'String#unicode_normalize' from -e:1:in 'block in <main>' -e:1:in 'Ractor#value': thrown by remote Ractor. (Ractor::RemoteError) from -e:1:in '<main>' /opt/local/lib/ruby/4.1.0+4/unicode_normalize/normalize.rb:138:in 'UnicodeNormalize.normalize': can not access non-shareable objects in constant UnicodeNormalize::NF_HASH_C by non-main ractor. (Ractor::IsolationError) from -e:1:in 'String#unicode_normalize' from -e:1:in 'block in <main>' ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126538] [Ruby Feature#22277] Make `rb_gc_register_address` Ractor-local
by eightbitraptor (Matt V-H) 07 Sep '26

07 Sep '26

Issue #22277 has been reported by eightbitraptor (Matt V-H). ---------------------------------------- Feature #22277: Make `rb_gc_register_address` Ractor-local https://bugs.ruby-lang.org/issues/22277 * Author: eightbitraptor (Matt V-H) * Status: Open * Assignee: eightbitraptor (Matt V-H) * Target version: 4.1 ---------------------------------------- ## Summary [Github PR #18393](https://github.com/ruby/ruby/pull/18393) `rb_gc_register_address` stores its entries in a single VM-wide list. This means that every Ractor local GC walks the list under a VM wide lock, which causes contention between Ractors attempting to GC. The associated PR changes the storage to per-ractor lists, removing the lock. However, due to potential Ractor isolation issues, we've restricted `rb_gc_register_address` and `rb_gc_unregister_address` to the main ractor. We would like to have a discussion about this restriction before going ahead with this change. ## Background Each ractor owns an objspace. A local GC marks only that ractor's roots and sweeps only its own pages. Using a VM-wide list with this design means that: - Every ractor's local GC scans every slot, under a shared lock. - A slot can name an object in another ractor's objspace. - If ractor A registers a slot and the slot's value is an unshareable object owned by ractor B, every ractor's GC marks the object. Storing it there violates the Ractor isolation guarantees, but the object stays alive, so it works. Changing this so that each Ractor maintains it's own list changes this so that only the registering Ractor's GC scans it's own list, which means we don't need to do this under a lock. However this introduces a situation where a slot on Ractor A's list holds an unshareable object owned by Ractor B, then Ractor B's local GC will not scan A's list, and A's local GC won't mark objects in B's objspace (because mark_maybe filters by objspace). This means that B can collect the object while A holds a reference to it, leading to a potential use-after-free. Because `rb_gc_register_address` and `rb_gc_unregister_address` are part of the public C API. It's tough to enforce a contract that restricts a slots value to one that's either shareable or owned by the main Ractor, because we register addresses, and any C extension can manipulate the value at that address at any time. ## Implementation detail The associated PR adds a "registered_addrs" array and a listed flag to each `rb_ractor_t` instance. When an address registered the Ractor in question is added to a VM local registry of Ractors who's lists are not empty, so that any calls to `rb_gc_unregister_address` can find the registering Ractor easily. Each Ractor local GC marks the current ractors list via `rb_ractor_mark_local_roots` and each Global GC marks every Ractors list, including terminated Ractors whose structs haven't been freed yet. The `rb_gc_register_address` and `rb_gc_unregister_address` functions now raise `Ractor::UnsafeError` when run from a non-main Ractor. This is a fairly blunt mechanism for ensuring that we can't end up with dangling pointers, but does restrict the usage of this API in ways that might be problematic. ## Concerns The main concern with this approach is the main Ractor only restriction? This is a semantic change from how the existing API works, and does restrict the functionality somewhat. This will only affect gems with C extensions that register and unregister objects dynamically at runtime. Registration during `Init_` functions still runs on the main Ractor and is unaffected. On 2026-08-25 we ran a codesearch over an index of published gems, looking for gems that both call `rb_ext_ractor_safe(true)` to declare themselves ractor safe and also call `rb_gc_register_address`. We found a total of 14 packages that matched both calls. Of which 6 were forks of other packages also in the list. Of the remaining 8 packages, 5 contained `rb_gc_register_address` calls that were _only_ within `Init_` functions. These would be unaffected by the change. The remaining 3 are [`oj`](https://rubygems.org/gems/oj), [`ox`](https://rubygems.org/gems/ox), and [`stack_trace`](https://rubygems.org/gems/stack_trace). Given the infrequency of this usage in real world Ruby applications. Should we add some documentation around `rb_gc_register_address` to document it's restricted usage, and patch the affected gems upstream? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126583] [Ruby Bug#18473] Raw data in Socket::Option#inspect on Amazon Linux 2
by wanabe (_ wanabe) 06 Sep '26

06 Sep '26

Issue #18473 has been updated by wanabe (_ wanabe). Status changed from Open to Third Party's Issue I was able to reproduce the issue using Vagrant, VirtualBox, `bento/ubuntu-18.04`, and Docker. This issue appears to occur with specific combinations of linux kernel versions and Alpine Linux. Therefore, I believe this is a third-party's issue. Alpine on 4.15.0-206: NG ``` $ vagrant ssh -c 'uname -a; printf "require \"socket\"; tcp_server = TCPServer.new(\"127.0.0.1\", 9000); tcp_server.setsockopt(Socket::SOL_SOCKET, Socket::SO_REUSEADDR, true); tcp_server.listen 1024; puts tcp_server.getsockopt(Socket::SOL_TCP, Socket::TCP_INFO).inspect; tcp_server.close" > a.rb; sudo docker run --rm -it -v.:/work ruby:3.1.0-alpine3.15 ruby /work/a.rb' Linux vagrant 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux #<Socket::Option: INET TCP INFO "\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"> ``` Debian (bullseye) on 4.15.0-206: OK ``` $ vagrant ssh -c 'uname -a; printf "require \"socket\"; tcp_server = TCPServer.new(\"127.0.0.1\", 9000); tcp_server.setsockopt(Socket::SOL_SOCKET, Socket::SO_REUSEADDR, true); tcp_server.listen 1024; puts tcp_server.getsockopt(Socket::SOL_TCP, Socket::TCP_INFO).inspect; tcp_server.close" > a.rb; sudo docker run --rm -it -v.:/work ruby:3.1.0-bullseye ruby /work/a.rb' Linux vagrant 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux #<Socket::Option: INET TCP INFO state=LISTEN ca_state=Open retransmits=0 probes=0 backoff=0 options=0 rto=0.000000s ato=0.000000s snd_mss=0 rcv_mss=0 unacked=0 sacked=128 lost=0 retrans=0 fackets=0 last_data_sent=0.000s last_ack_sent=0.000s last_data_recv=0.000s last_ack_recv=0.000s pmtu=0 rcv_ssthresh=0 rtt=0.000000s rttvar=0.000000s snd_ssthresh=0 snd_cwnd=10 advmss=0 reordering=3 rcv_rtt=0.000000s rcv_space=0 total_retrans=0 (88 bytes too long)> ``` Alpine on 5.4.0-37: OK ``` $ vagrant ssh -c 'uname -a; printf "require \"socket\"; tcp_server = TCPServer.new(\"127.0.0.1\", 9000); tcp_server.setsockopt(Socket::SOL_SOCKET, Socket::SO_REUSEADDR, true); tcp_server.listen 1024; puts tcp_server.getsockopt(Socket::SOL_TCP, Socket::TCP_INFO).inspect; tcp_server.close" > a.rb; sudo docker run --rm -it -v.:/work ruby:3.1.0-alpine3.15 ruby /work/a.rb' Linux vagrant 5.4.0-37-generic #41~18.04.1-Ubuntu SMP Mon Jun 8 13:37:29 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux #<Socket::Option: INET TCP INFO state=LISTEN ca_state=Open retransmits=0 probes=0 backoff=0 options=0 rto=0.000000s ato=0.000000s snd_mss=0 rcv_mss=0 unacked=0 sacked=1024 lost=0 retrans=0 fackets=0 last_data_sent=0.000s last_ack_sent=0.000s last_data_recv=0.000s last_ack_recv=0.000s pmtu=0 rcv_ssthresh=0 rtt=0.000000s rttvar=0.000000s snd_ssthresh=0 snd_cwnd=10 advmss=0 reordering=3 rcv_rtt=0.000000s rcv_space=0 total_retrans=0 snd_wnd=0 rcv_ooopack=0> ``` Alpine on 5.3.0-76: NG ``` $ vagrant ssh -c 'printf "system \"uname -a\"; require \"socket\"; tcp_server = TCPServer.new(\"127.0.0.1\", 9000); tcp_server.setsockopt(Socket::SOL_SOCKET, Socket::SO_REUSEADDR, true); tcp_server.listen 1024; puts tcp_server.getsockopt(Socket::SOL_TCP, Socket::TCP_INFO).inspect; tcp_server.close" > a.rb; sudo docker run --rm -it -v.:/work ruby:3.1.0-alpine3.15 ruby /work/a.rb' Linux d1e29cb69509 5.3.0-76-generic #72-Ubuntu SMP Thu Jul 15 10:51:23 UTC 2021 x86_64 Linux #<Socket::Option: INET TCP INFO "\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"> ``` ---------------------------------------- Bug #18473: Raw data in Socket::Option#inspect on Amazon Linux 2 https://bugs.ruby-lang.org/issues/18473#change-118793 * Author: driv3r (Leszek Zalewski) * Status: Third Party's Issue * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux-musl] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Hello, I found a weird issue when running attached script. Locally on Ubuntu running kernel 5.11, on CI (GitHub Actions) and through docker image (ruby:3.1.0-alpine3.15), the response is as it should be with all data parsed correctly: ``` ruby #<Socket::Option: INET TCP INFO state=LISTEN ca_state=Open retransmits=0 probes=0 backoff=0 options=0 rto=0.000000s ato=0.000000s snd_mss=0 rcv_mss=0 unacked=0 sacked=1024 lost=0 retrans=0 fackets=0 last_data_sent=0.000s last_ack_sent=0.000s last_data_recv=0.000s last_ack_recv=0.000s pmtu=0 rcv_ssthresh=0 rtt=0.000000s rttvar=0.000000s snd_ssthresh=0 snd_cwnd=10 advmss=0 reordering=3 rcv_rtt=0.000000s rcv_space=0 total_retrans=0 (128 bytes too long)> ``` The issue happens when running exactly the same docker image on AWS Fargate, where instead of expected output above, we get ```ruby "#<Socket::Option: INET TCP INFO \"\\n\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x80\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\n\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x03\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\xFF\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\">" ``` After further testing even simple EC2 with Amazon Linux 2 @4.14 kernel gives same output, 5.10 works fine. Steps to reproduce: - boot up EC2 instance with Amazon Linux v2 @ kernel 4.14 (no idea how to run it locally, I might assist if needed) - install docker ```bash sudo yum install docker sudo systemctl start docker.service sudo docker run -it ruby:3.1.0-alpine3.15 ``` - execute the attached script ---Files-------------------------------- test.rb (246 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126564] [Ruby Bug#22290] Adding instance variables to anonymous object may bloat all future classes
by byroot (Jean Boussier) 06 Sep '26

06 Sep '26

Issue #22290 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22290: Adding instance variables to anonymous object may bloat all future classes https://bugs.ruby-lang.org/issues/22290 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction script: ```ruby o = Object.new 10.times do |i| o.instance_variable_set("@a_#{i}", 1) end class Test def initialize(a, b) @a = a @b = b end end require 'objspace' p ObjectSpace.memsize_of(Test.new(1, 2)) ``` Expected: ``` 40 # or 32 on 4.1.dev ``` Actual: ``` 160 ``` ### Explanation `Class` records the max number of instance variables any of its instances held (`max_iv_count`). When inheriting from a class, `max_iv_count` is copied in the child class. If you add instance variables to an instance of `Object`, any future direct children of `Object` will start with a larger than needed `max_iv_count` and will cause Ruby to potentially allocate much larger objects than needed. All versions since 3.2 are affected, the issue was fixed on master a couple months. I believe we should backport the fix (I'm working on it), because otherwise some un-proper code running early in the process life-cycle can cause significant memory waste. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126513] [Ruby Bug#22269] `Coverage.line_stub` clobbers already-collected coverage data
by mugikurash (Shuta Mugikura) 06 Sep '26

06 Sep '26

Issue #22269 has been reported by mugikurash (Shuta Mugikura). ---------------------------------------- Bug #22269: `Coverage.line_stub` clobbers already-collected coverage data https://bugs.ruby-lang.org/issues/22269 * Author: mugikurash (Shuta Mugikura) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-27T01:47:31Z master 5ee95de080) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Coverage.line_stub` compiles the file with `compile_file` only to read the ISeq's `trace_points`. Since https://bugs.ruby-lang.org/issues/22018 `compile_file` registers the file into the coverage table, so calling `line_stub` while `Coverage` is running resets the file's already-collected counters. This also reproduces on 3.4 and 4.0, so I would like it backported. Reproduction: ```ruby require "coverage" f = File.expand_path("m.rb") File.write(f, "def m\n :ok\nend\n") Coverage.start require f m p Coverage.peek_result[f] Coverage.line_stub(f) p Coverage.peek_result[f] m p Coverage.result[f] ``` Expected: ``` [1, 1, nil] [1, 1, nil] [1, 2, nil] ``` Actual: ``` [1, 1, nil] [0, 0, nil] [0, 0, nil] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120897] [Ruby master Bug#21119] Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly.
by genya0407 (Yusuke Sangenya) 05 Sep '26

05 Sep '26

Issue #21119 has been reported by genya0407 (Yusuke Sangenya). ---------------------------------------- Bug #21119: Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly. https://bugs.ruby-lang.org/issues/21119 * Author: genya0407 (Yusuke Sangenya) * Status: Open * ruby -v: ruby 3.5.0dev (2025-02-06T14:10:34Z master adbf9c5b36) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Executing the following code in Ruby 3.4.1 takes a very long time, especially when there are many files $100~$ in the current directory. This delay does not occur in Ruby 3.3.6. ## Reproducible script ```ruby # hoge.rb # Launch a thread to execute CPU-heavy task Thread.new do loop do arr = [] 100.times do arr << rand(1...100) end end end # Execute a program containing `Dir.glob` in the main thread. 10.times do Dir.glob('*') puts "aaaa" end ``` ## Execution Results Executiong the above code in Ruby 3.4.1 takes **119.43s**. ```shell $ ruby -v ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] $ time ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ruby hoge.rb 119.43s user 0.30s system 99% cpu 1:59.89 total ``` Executing it in Ruby master also takes **118.87s**. ```shell $ ~/opt-ruby/bin/ruby -v ruby 3.5.0dev (2025-02-06T14:10:34Z master adbf9c5b36) +PRISM [arm64-darwin24] $ time ~/opt-ruby/bin/ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ~/opt-ruby/bin/ruby hoge.rb 118.87s user 0.46s system 99% cpu 2:00.45 total ``` Executing it in Ruby 3.3.6 takes only **2.22s**. ```shell $ ruby -v ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [arm64-darwin24] $ time ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ruby hoge.rb 2.22s user 0.03s system 98% cpu 2.286 total ``` So, there are roughly **50x** delays. ## Possible Cause From Ruby 3.4.0, `Dir.glob` releases the GVL frequently. * https://bugs.ruby-lang.org/issues/20587 * https://github.com/ruby/ruby/pull/11147 Due to this change, when a CPU-heavy thread releases the GVL, `Dir.glob` also releases the GVL immediately. As a result, `Dir.glob` gets significantly delayed because it has to continuously regain the GVL causing a major slowdown in execution. ## Note about Execution Results I measured the execution results under a stress condition, with 100 files in the current directory. If there are fewer files, the slowdown may be less pronounced. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:126568] [Ruby Bug#19017] Net::HTTP may block when attempting to reuse a persistent connection
by joshc (Josh C) 04 Sep '26

04 Sep '26

Issue #19017 has been updated by joshc (Josh C). I think we're all in agreement that mixing non-blocking read with blocking eof? is a recipe for disaster. I would welcome a non-blocking eof? check in IO that Net::HTTP can just call. Hopefully https://bugs.ruby-lang.org/issues/20215 can be implemented and merged. PR https://github.com/ruby/net-http/pull/232 looks good to me as an immediate solution. I know it's not ideal for Net::HTTP to reach into IO, but I don't know if/when #20215 will be implemented. I just ran into this issue again and found it happens trivially with Jetty 10/11, because it opportunistically sends [NewSessionTicket on an idle connection along with an empty message](https://github.com/jetty/jetty.project/blob/1e95549f1aa70c1760de8f…. The [`NEED_WRAP`](https://github.com/openjdk/jdk/blob/f1c7c3e9bc0c8794dbf16b4fdc31464d5abe473b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java#L139-L146) comes from the SSLEngine indicating "I have data to send" In Jetty 12, the problem doesn't seem to occur. I believe this is because they rewrote the core IO, and NewSessionTickets are always sent on the next active response, never on an idle socket. ---------------------------------------- Bug #19017: Net::HTTP may block when attempting to reuse a persistent connection https://bugs.ruby-lang.org/issues/19017#change-118777 * Author: joshc (Josh C) * Status: Open * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Ruby's Net::HTTP code performs a blocking `Net::BufferedIO#eof?` check when attempting to reuse a persistent HTTP connection. See https://github.com/ruby/ruby/blob/6b099328af2ae2d04cbfd06fedc36a19cdecd30d/…. The bug is the check can hang for up to the HTTP `read_timeout`, which is 60 seconds by default. The code calls `TCPSocket#wait_readable(0)` to see if the socket is readable before calling the blocking `eof?` method. However, it's possible for the socket to be readable with SSL Handshake records and no Application Data. So the call to `eof?` will process the SSL Handshake records, but hang since no Application Data is available. The issue can be triggered if a TLS 1.3 server sends a `NewSessionTicket` sometime after Application Data is written. The attached client and server code demonstrate the problem. Note it's important that the client and server be on separate hosts otherwise `eof?` will always return immediately. On the server, copy `Server.java` and `certs.p12` into a directory, install JDK 17, compile the server and run it: ``` $ openssl pkcs12 -info -in certs.p12 -noout -passin pass:password MAC: sha1, Iteration 2048 MAC length: 20, salt length: 8 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 $ sudo apt install -y openjdk-17-jdk openjdk-17-jre $ javac Server.java $ java -Djavax.net.debug=ssl,verbose Server Loaded pkcs12 ``` On the client, copy `http.rb` and `ca.pem` into a directory, add the IP address for the server as `pluto` to `/etc/hosts`: ``` $ file ca.pem $ sudo vi /etc/hosts ... 192.168.0.10 pluto ... $ ruby --version ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux] $ openssl version OpenSSL 1.1.1f 31 Mar 2020 ``` Run the client to make the first request: ``` $ ruby http.rb opening connection to pluto:8888... opened starting SSL for pluto:8888... ``` The server will handle request_1 and trigger a new session ticket: ``` javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:23.269 UTC|SSLCipher.java:466|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 Connected to 37532 Handling request_0 ... snip ... javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:25.310 UTC|SSLCipher.java:2024|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:25.335 UTC|SSLCipher.java:1870|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 read body updated session data javax.net.ssl|ALL|10|main|2022-09-22 18:18:25.343 UTC|SSLSocketImpl.java:1564|trigger new session ticket wrote response Handling request_1 ``` The client will hang when trying to reuse the persistent connection: ``` OSSL_DEBUG: SSL SESSION new callback added [ossl_ssl.c:963] SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384 <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] ``` Pressing Ctrl-C shows the backtrace: ``` ^CTraceback (most recent call last): 11: from http.rb:10:in `<main>' 10: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:933:in `start' 9: from http.rb:17:in `block in <main>' 8: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1294:in `post' 7: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1506:in `send_entity' 6: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1492:in `request' 5: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1518:in `transport_request' 4: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1573:in `begin_transport' 3: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/protocol.rb:134:in `eof?' 2: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:300:in `eof?' 1: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:57:in `fill_rbuff' /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:57:in `sysread': Interrupt ``` I get the same behavior with latest ruby too: ``` $ ruby --version ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] ``` Changing Net::HTTP to the following: ``` elsif @socket.io.read_nonblock(0, exception: false).nil? ``` Resolves the issue: ``` $ ruby http.rb opening connection to pluto:8888... opened starting SSL for pluto:8888... OSSL_DEBUG: SSL SESSION new callback added [ossl_ssl.c:963] SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384 <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive ``` However, based on https://github.com/ruby/ruby/pull/1089#issuecomment-159878003 that change may not be correct. Or it could be that Ruby on Windows doesn't have this issue anymore. ---Files-------------------------------- Server.java (3.75 KB) http.rb (423 Bytes) ca.pem (8.43 KB) certs.p12 (2.24 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126558] [Ruby Bug#22287] Prism aborts in pm_newline_list_append when requiring a file after fork
by Morred (Laura Eck) 04 Sep '26

04 Sep '26

Issue #22287 has been reported by Morred (Laura Eck). ---------------------------------------- Bug #22287: Prism aborts in pm_newline_list_append when requiring a file after fork https://bugs.ruby-lang.org/issues/22287 * Author: Morred (Laura Eck) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby crashed on me while I was running our precommit hooks, during the Rubocop step, with the following output: ``` Assertion failed: (list->size == 0 || newline_offset > list->offsets[list->size - 1]), function pm_newline_list_append, file pm_newline_list.c, line 51. /Users/laura.eck/Projects/jeancaisse/lib/constants/feature_flags.rb: [BUG] Aborted at 0x000000018415c5e8 ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/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:0055 p:---- s:0300 e:000299 l:y b:---- DUMMY [FINISH] c:0054 p:---- s:0297 e:000296 l:y b:0001 CFUNC :require_relative c:0053 p:0005 s:0292 e:000291 l:y b:0001 TOP /Users/laura.eck/Projects/<redacted>/lib/cops/<redacted>/dx/feature_flag_setup.rb:3 [FINISH] c:0052 p:---- s:0289 e:000288 l:y b:0001 CFUNC :require c:0051 p:0033 s:0284 e:000283 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60 c:0050 p:0023 s:0278 e:000277 l:n b:---- BLOCK /Users/laura.eck/Projects/<redacted>/lib/cops.rb:46 [FINISH] c:0049 p:0027 s:0274 e:000273 l:y b:0001 METHOD <internal:array>:228 c:0048 p:0096 s:0268 e:000267 l:y b:0001 TOP /Users/laura.eck/Projects/<redacted>/lib/cops.rb:43 [FINISH] c:0047 p:---- s:0265 e:000264 l:y b:0001 CFUNC :require c:0046 p:0033 s:0260 e:000259 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60 c:0045 p:0006 s:0254 e:000253 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:35 c:0044 p:0020 s:0248 e:000247 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:21 c:0043 p:0083 s:0241 e:000240 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:32 [FINISH] c:0042 p:0027 s:0236 e:000235 l:y b:0001 METHOD <internal:array>:228 c:0041 p:0008 s:0230 e:000229 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:21 c:0040 p:0003 s:0226 e:000225 l:y b:0001 METHOD <internal:kernel>:91 c:0039 p:0017 s:0222 e:000221 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:20 c:0038 p:0060 s:0215 e:000214 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:63 c:0037 p:0022 s:0202 e:000201 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:128 c:0036 p:0089 s:0194 e:000190 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:73 c:0035 p:0007 s:0185 e:000184 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:52 c:0034 p:0010 s:0181 e:000180 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:92 c:0033 p:0015 s:0178 e:000177 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cache_config.rb:9 c:0032 p:0023 s:0173 e:000172 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:91 c:0031 p:0050 s:0166 e:000164 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:172 c:0030 p:0018 s:0160 e:000159 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:49 c:0029 p:0011 s:0157 e:000156 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:89 c:0028 p:0069 s:0147 e:000146 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:45 c:0027 p:0035 s:0138 e:000137 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/exec.rb:22 c:0026 p:0004 s:0133 e:000132 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:24 [FINISH] c:0025 p:---- s:0130 e:000129 l:y b:0001 CFUNC :chdir c:0024 p:0012 s:0125 e:000124 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:23 c:0023 p:0007 s:0121 e:000120 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:33 c:0022 p:0059 s:0118 e:000117 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/helper.rb:26 c:0021 p:0056 s:0106 e:000105 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:28 c:0020 p:0019 s:0100 e:000099 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:93 c:0019 p:0014 s:0094 e:000093 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:68 c:0018 p:0012 s:0091 e:000090 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:131 c:0017 p:0005 s:0087 e:000086 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:67 c:0016 p:0052 s:0083 e:000082 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:56 [FINISH] c:0015 p:---- s:0080 e:000079 l:y b:0001 CFUNC :fork c:0014 p:0008 s:0076 e:000075 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:47 c:0013 p:0042 s:0071 e:000070 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:39 c:0012 p:0063 s:0063 e:000062 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:4 c:0011 p:0021 s:0057 e:000056 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:120 [FINISH] c:0010 p:---- s:0052 e:000051 l:y b:0001 CFUNC :open c:0009 p:0010 s:0046 e:000045 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:117 c:0008 p:0033 s:0042 e:000041 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:2 c:0007 p:0085 s:0038 e:000037 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:93 c:0006 p:0156 s:0031 e:000030 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:83 c:0005 p:0041 s:0023 e:000022 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:49 c:0004 p:0043 s:0018 e:000017 l:y b:0001 TOP /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/exe/rubocop:8 [FINISH] c:0003 p:---- s:0013 e:000012 l:y b:0001 CFUNC :load c:0002 p:0111 s:0008 E:0019d0 l:n b:---- EVAL bin/rubocop:52 [FINISH] c:0001 p:0000 s:0003 E:002250 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bin/rubocop:52:in '<main>' bin/rubocop:52:in 'load' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/exe/rubocop:8:in '<top (required)>' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:49:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:83:in 'process_arguments' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:93:in 'run_command' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:29:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:117:in 'acquire_lock' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:117:in 'open' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:120:in 'block in acquire_lock' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:42:in 'block in run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:39:in 'start' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:47:in 'detach_server' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:47:in 'fork' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:56:in 'block in detach_server' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:67:in 'process_input' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:131:in 'write_pid_file' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:68:in 'block in process_input' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:93:in 'read_socket' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:28:in 'read!' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/helper.rb:26:in 'redirect' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:33:in 'block in read!' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:23:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:23:in 'chdir' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:24:in 'block in run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/exec.rb:22:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:45:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:89:in 'profile_if_needed' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:49:in 'block in run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:172:in 'act_on_options' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:91:in 'cache_root' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cache_config.rb:9:in 'root_dir' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:92:in 'block in cache_root' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:52:in 'for_pwd' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:73:in 'for_dir' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:128:in 'configuration_from_file' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:63:in 'load_file' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:20:in 'resolve_requires' <internal:kernel>:91:in 'tap' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:21:in 'block in resolve_requires' <internal:array>:228:in 'each' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:32:in 'block (2 levels) in resolve_requires' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:21:in 'load' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:35:in 'load' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /Users/laura.eck/Projects/jeancaisse/lib/cops.rb:43:in '<top (required)>' <internal:array>:228:in 'each' /Users/laura.eck/Projects/<redacted>/lib/cops.rb:46:in 'block in <top (required)>' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /Users/laura.eck/Projects/<redacted>/lib/cops/<redacted>/dx/feature_flag_setup.rb:3:in '<top (required)>' /Users/laura.eck/Projects/<redacted>/lib/cops/<redacted>/dx/feature_flag_setup.rb:3:in 'require_relative' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x000000000000002e x6: 0x0000000000000000 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x0000000000000203 x21: 0x00000001f0bd6260 x22: 0x0000000000000001 x23: 0x0000000101f471a1 x24: 0x00000001ee10a000 x25: 0x0000000000000001 x26: 0x000000016eed28b0 x27: 0x0000000101f6d3f8 x28: 0x0000000000000001 lr: 0x00000001841978d8 fp: 0x000000016eed23f0 sp: 0x000000016eed23d0 -- C level backtrace information ------------------------------------------- /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(rb_vm_bugreport+0xbc8) [0x101ce9fc4] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(rb_bug_for_fatal_signal+0x10c) [0x101b066a0] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(sigabrt+0x90) [0x101c3c228] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x1841a1744] /usr/lib/system/libsystem_pthread.dylib(pthread_kill+0x128) [0x1841978d8] /usr/lib/system/libsystem_c.dylib(abort+0x94) [0x18409d978] [0x18409cbd4] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_newline_list_append.cold.2+0x0) [0x101f163b8] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_newline_list_append+0x0) [0x101d32b90] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_parser_lex+0xe1c) [0x101d36850] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_parse+0x88) [0x101d34110] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_parse_file+0xb0) [0x101a9184c] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_load_iseq_eval+0xa4) [0x101b7b17c] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_require_internal+0x31c) [0x101b79314] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_require_string_internal+0x60) [0x101b78890] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_vm_call_cfunc_with_frame_+0xf0) [0x101cd97f0] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_vm_exec_core+0x2378) [0x101cbbd08] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_vm_exec+0x268) [0x101cb7d2c] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_load_iseq_eval+0x230) [0x101b7b308] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_require_internal+0x31c) [0x101b79314] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_require_string_internal+0x60) [0x101b78890] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_f_require+0x44) [0x101b78758] -- Other runtime information ----------------------------------------------- * Loaded script: rubocop --server /Users/laura.eck/Projects/<redacted> [I'm omitting the rest of the 3500 line output] ``` Crash report file is attached to this ticket. Please let me know if I can help out with any more information. ---Files-------------------------------- ruby-2026-09-03-133824.ips (20.8 KB) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126559] [Ruby Bug#22288] doc: Pathname: rmtree is claimed to return 0, it actually returns self
by akim2 (Akim Demaille) 03 Sep '26

03 Sep '26

Issue #22288 has been reported by akim2 (Akim Demaille). ---------------------------------------- Bug #22288: doc: Pathname: rmtree is claimed to return 0, it actually returns self https://bugs.ruby-lang.org/issues/22288 * Author: akim2 (Akim Demaille) * Status: Open * ruby -v: 4.0 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

1 0