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

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

07 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:126235] [Ruby Feature#22226] Ractor: class/module ownership -- restrict modification to the Ractor that created it
by ko1 (Koichi Sasada) 07 Sep '26

07 Sep '26

Issue #22226 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22226: Ractor: class/module ownership -- restrict modification to the Ractor that created it https://bugs.ruby-lang.org/issues/22226 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Target version: 4.1 ---------------------------------------- ## Abstract Every class/module records the Ractor that created it as its *owner*. Only the owner Ractor can modify it. Reading is unchanged and allowed from any Ractor. This replaces several ad-hoc "main Ractor only" rules with a single rule keyed on the creator. It **relaxes** the rules for classes a Ractor creates itself, and **tightens** them for classes created by somebody else. No Ruby-level API is added: ownership is recorded internally and is not exposed. --- ## 1. Motivation ### 1.1 The current rules ask the wrong question Today's restrictions ask *"are you the main Ractor?"*. They never ask *"did you create this class?"*. The result is inconsistent in both directions. A non-main Ractor may freely redefine **any** class in the process: ```ruby class C; end Ractor.new { C.define_method(:m) { 1 }; :done }.value #=> :done (works today) Ractor.new { class String; def foo = 1; end; :done }.value #=> :done (works today) Ractor.new { def f = 42; f() }.value #=> 42 (works today; defines Object#f) Ractor.new { Object.send(:remove_const, :FOO); :done }.value #=> :done (works today) ``` ...but it may **not** set an instance variable on a class it created itself: ```ruby Ractor.new { k = Class.new # nobody else can even name this class yet k.instance_variable_set(:@iv, 1) }.value #=> Ractor::IsolationError: # can not set instance variables of classes/modules by non-main Ractors ``` ...nor give it an unshareable constant: ```ruby Ractor.new { k = Class.new k.const_set(:X, "str".dup) }.value #=> Ractor::IsolationError: # can not set constants with non-shareable objects by non-main Ractors ``` The first group is unrestricted although it affects the whole process. The second group is forbidden although it affects nothing but the Ractor doing it. The rules are exactly inverted with respect to who is actually affected. ### 1.2 A Ractor's classes can be redefined under it by another Ractor Because any Ractor may modify any class, the code a Ractor runs can be changed by somebody else at any moment: ```ruby Ractor.new { class String; def upcase = :patched; end; :done }.value "abc".upcase #=> :patched # evaluated in the *main* Ractor ``` ```ruby FOO = 1 Ractor.new { Object.send(:remove_const, :FOO); :removed }.value FOO #=> NameError: uninitialized constant FOO ``` Both of these run fine today. There is no way for a Ractor to rely on the classes it uses. ### 1.3 Class internals have no single writer `m_tbl`, `const_tbl` and the class fields can be written by any Ractor today. This means the implementation cannot assume a single writer for any class, which stands in the way of synchronization and caching work (and it is also how the `cvar_overtaken()` bug below arose: a *read* path physically deletes a table entry, potentially of another Ractor's class). --- ## 2. Proposal A class/module records its creator Ractor as its **owner**. Only the owner may: * define/remove/undef methods, `alias`, change method visibility * `include`/`prepend` into it, and `Module#refine` targeting it * define/remove constants, register `autoload` * set instance variables on the class/module object Non-owner Ractors get `Ractor::IsolationError`. **Reading is completely unchanged**: method calls, instantiation, subclassing, constant reads and instance-variable reads all work from any Ractor as before. In exchange, the previous "main Ractor only" rules for class instance variables and unshareable constant values become "**owner Ractor only**". A Ractor gets full use of the classes it creates. Since all classes/modules created at boot or by main-Ractor code (including everything loaded by `require`) are owned by the main Ractor, this is equivalent to today's rules for programs that do not create classes inside non-main Ractors. --- ## 3. Examples ### 3.1 Newly allowed: a Ractor can fully use the classes it creates Instance variables on a class the Ractor created: ```ruby Ractor.new { k = Class.new k.instance_variable_set(:@iv, 1) # was: IsolationError, even for a shareable value! k.instance_variable_set(:@iv, "str".dup) # was: IsolationError k.instance_variable_get(:@iv) #=> "str" }.value ``` **Unshareable values in constants** of a class the Ractor created. This was the main Ractor's privilege before; now every Ractor has it for its own classes: ```ruby Ractor.new { k = Class.new k::BUF = "buffer".dup # unshareable value; was: IsolationError k::BUF << "!" # ...and the owner can freely use it k::BUF #=> "buffer!" }.value Ractor.new { k = Class.new k.const_set(:LIST, [1, 2, 3]) # an unfrozen Array is unshareable too k::LIST << 4 k::LIST #=> [1, 2, 3, 4] }.value ``` The value stays private to the owner -- reading it from another Ractor raises, which is exactly the rule that applied to the main Ractor before: ```ruby port = Ractor::Port.new r = Ractor.new(port) { |pt| k = Class.new; k::BUF = "buffer".dup; pt << k; Ractor.receive } k = port.receive k::BUF #=> Ractor::IsolationError: can not access non-shareable objects in constant # #<Class:0x...>::BUF of a class/module created by another Ractor. ``` A *shareable* value in the same position is readable from anywhere, as before: ```ruby r = Ractor.new(port) { |pt| k = Class.new; k::N = 42; pt << k; Ractor.receive } k = port.receive k::N #=> 42 ``` Classes defined under a module the Ractor created itself work fully: ```ruby Ractor.new { mod = Module.new mod.const_set(:Foo, Class.new { def m = :ok }) mod::Foo.new.m #=> :ok }.value ``` ### 3.2 Newly prohibited: modifying a class created by another Ractor ```ruby class C; end module M; end Ractor.new { def f = 42 }.value #=> can not modify Object because it is created by another Ractor # (top-level `def` defines a private method on Object) Ractor.new { class String; def foo = 1; end }.value #=> can not modify String because it is created by another Ractor Ractor.new { C.define_method(:m) { 1 } }.value Ractor.new { C.send(:alias_method, :a, :inspect) }.value Ractor.new { C.send(:private, :inspect) }.value Ractor.new { C.send(:undef_method, :inspect) }.value Ractor.new { C.include(M) }.value Ractor.new { C.prepend(M) }.value Ractor.new { Module.new { refine(C) { def z = 1 } } }.value Ractor.new { C.autoload(:Zz, "zz") }.value #=> can not modify C because it is created by another Ractor Ractor.new { C.const_set(:X, 1) }.value # note: even a *shareable* value now raises #=> can not set constants of classes/modules created by another Ractor Ractor.new { class TopCls; end }.value # a top-level class name... Ractor.new { module TopMod; end }.value # ...and a top-level module name #=> can not set constants of classes/modules created by another Ractor # (both write a constant into Object) Ractor.new { Object.send(:remove_const, :FOO) }.value #=> can not modify Object because it is created by another Ractor Ractor.new { C.instance_variable_set(:@iv, 1) }.value #=> can not set instance variables of classes/modules created by another Ractor ``` Patterns that stop working: ```ruby # a registry in Class#inherited that writes into the superclass Base = Class.new { def self.inherited(sub) = const_set(:"Sub#{sub.object_id}", sub) } Ractor.new { Class.new(Base) }.value #=> can not set constants of classes/modules created by another Ractor # lazy definition on first touch M2 = Module.new { def self.const_missing(n) = const_set(n, Class.new) } Ractor.new { M2::Foo }.value #=> can not set constants of classes/modules created by another Ractor ``` Both work if the definition happens before the Ractor is spawned (eager loading). ### 3.3 Unchanged ```ruby Ractor.new { "abc".upcase }.value #=> "ABC" Ractor.new { C.new }.value # instantiation Ractor.new { Class.new(String) { def m = :ok }.new.m }.value #=> :ok (subclassing is creation) Ractor.new { require "time"; Time.now.respond_to?(:xmlschema) }.value #=> true ``` `require` from a non-main Ractor keeps working because `Ractor#require` performs the load on the main Ractor, so the library's classes are defined by (and owned by) the main Ractor. `def` on an object a Ractor created is also unaffected -- an ordinary object's singleton class is created by, and owned by, the Ractor that triggers it: ```ruby Ractor.new { o = Object.new; def o.f = :ok; o.f }.value #=> :ok ``` ### 3.4 Summary table | operation from a non-main Ractor | today | proposal | |---|---|---| | define a method on a foreign class | OK | **IsolationError** | | top-level `def` | OK | **IsolationError** | | `include`/`prepend`/`refine` a foreign class | OK | **IsolationError** | | set a **shareable** constant on a foreign class | OK | **IsolationError** | | set an **unshareable** constant on a foreign class | IsolationError | IsolationError | | `remove_const` / `autoload` on a foreign class | OK | **IsolationError** | | set an ivar on a foreign class | IsolationError | IsolationError | | define a method on its **own** class | OK | OK | | set a **shareable** constant on its **own** class | OK | OK | | set an **unshareable** constant on its **own** class | IsolationError | **OK** | | set an ivar on its **own** class | IsolationError | **OK** | | read / call / instantiate / subclass any class | OK | OK | --- ## 4. How the proposal answers the motivation * **1.1 (rules ask the wrong question)** -- the rules now ask "did you create this?" instead of "are you main?". Every restriction is on the class of somebody else, and every relaxation is on your own class. The two inverted cases in 1.1 both flip to the right side. The old "main Ractor only" rules become the special case *"boot-time classes are owned by the main Ractor"*, so they are no longer separate rules. * **1.2 (classes changed under you)** -- no Ractor can modify a class it did not create, so the classes a Ractor uses cannot be redefined by another Ractor. * **1.3 (no single writer)** -- every class/module now has exactly one Ractor which can write its method table, constant table and fields. --- ## 5. What this does **not** give Ownership bounds *who may write*, not *what readers may see*. Reads stay unsynchronized and a class modification is not atomic, so a non-owner Ractor can still observe a class in the middle of being modified by its owner: after the first `def` of a `class ... end` body but before the second, or while `include`/`prepend` is rewiring the ancestor chain. The guarantee is **a single writer per class/module**, not a consistent view for readers. This proposal is not, and does not claim to be, full isolation of class state. --- ## 6. Details * **Singleton classes / metaclasses** are owned by the owner of the object they are attached to, not by the Ractor that happened to trigger their lazy creation. `def C.foo` is allowed exactly for the owner of `C`: ```ruby class C; end Ractor.new { C.singleton_class; :touched }.value # another Ractor touches it first class << C; def foo = :ok; end # still fine in main C.foo #=> :ok Ractor.new { class << C; def bar = 1; end }.value #=> IsolationError ``` * **Terminated owner**: a class whose owner Ractor has finished becomes permanently read-only for everybody, including the main Ractor. ```ruby K = Ractor.new { Class.new { def x = :made_in_ractor } }.value K.new.x #=> :made_in_ractor (reading is fine) K.define_method(:y) { 1 } #=> IsolationError (nobody owns it any more) ``` There is intentionally no API to look up or transfer ownership. * **Class variables** are *not* covered by the relaxation. They are shared across the whole inheritance chain and the class they are physically stored in can migrate over time (`cvar_overtaken`), so no single owner can be defined for them. Writes still require the main Ractor, and additionally must not cross the ownership boundary (the class actually written into must be owned), so class fields keep a single writer. * **Copying a foreign class**: `Class#dup`/`clone` of a class created by another Ractor produces a copy owned by the copying Ractor. It raises if the source's constants or instance variables refer to unshareable objects (they would leak across Ractors); copying classes holding only shareable values works. This gives a mutation-free alternative to monkey-patching: ```ruby S = Class.new; S.const_set(:OK, 1) Ractor.new { k = S.dup; k.define_method(:m) { 1 }; k.new.m }.value #=> 1 ``` * **Top-level class and module names**: `class Foo; end` / `module Foo; end` at the top level of a non-main Ractor writes a constant into `Object`, so both are prohibited. Define them under a module the Ractor creates itself instead (`mod = Module.new; mod.const_set(:Foo, Class.new)`). Integration with `Ruby::Box` is future work. * **Bug fix included**: `cvar_overtaken()` physically deleted a duplicated cvar entry from the `front` class, and that path is reachable from *read* operations (`rb_cvar_find`) -- i.e. a cross-Ractor write triggered by a read. The clean-up is now skipped unless the current Ractor owns `front`. --- ## 7. Incompatibility Only code that modifies classes from a non-main Ractor is affected. Concretely, the following raise `Ractor::IsolationError` where they used to work: * method definition / `alias` / visibility change on a foreign class, including top-level `def` * `include`/`prepend` into a foreign class, `refine` targeting one * setting a **shareable** constant on a foreign class, `remove_const`, `autoload` registration * `Class#inherited` and `const_missing`/`method_missing` hooks which mutate a foreign class Migration is usually "define it before spawning the Ractor" (eager loading), or "create the class inside the Ractor that uses it", or "`dup` the foreign class and modify the copy". Programs which never define classes inside non-main Ractors are unaffected. --- ## 8. Open questions / future work * `freeze` of a foreign class is still allowed. It is a behavior-changing write and should probably be owner-only too. * `Module#set_temporary_name` is not checked yet. * Singleton class ownership is not transferred by `Ractor#send(move: true)`. * Integration with `Ruby::Box`, so that non-main Ractors can define top-level class/module names. * Should the error message for a class owned by the main Ractor say "owned by the main Ractor" rather than "created by another Ractor"? The current wording is confusing for top-level `def`, where the user never mentioned `Object`. --- ## 9. Implementation https://github.com/ruby/ruby/pull/17913 The owner is stored in `rb_classext_t::owner_ractor` as the Ractor object; `0` means the main Ractor, so single-Ractor programs get no additional GC edges. It is marked from the classext and updated on compaction, so the comparison never sees a dangling or reused reference. Method-table checks funnel through `rb_class_modify_check()`; constant/ivar/cvar checks replace the previous `rb_ractor_main_p()` checks in `variable.c`. The class-ivar fast paths in `vm_insnhelper.c` switch from "main Ractor" to "owner Ractor", which keeps them valid because the owner is the only writer and its threads are serialized by the per-Ractor lock. `make btest` (2053 tests), `make test-all` (35797 tests, 0 failures / 0 errors) and `make test-spec` (32628 examples, 0 failures / 0 errors / 0 tagged) all pass. Three tests which relied on cross-Ractor method definition were rewritten so that the owner Ractor performs the definition. ## Notes * Above description is written by Claude code from my explanation. * The biggest motivation is "main-Ractor" exceptions. The concept "owner Ractor for classes/modules" solves this kind of exception. * Another idea for mutating the classes/modules is prohibit them on non-main Ractors because most of classes/modules are defined on the loading time on the main Ractor. However, it also prohibits `Class.new` in non-main Ractors, and it is common programming pattern on Ruby. -- https://bugs.ruby-lang.org/

4 7

[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) 04 Sep '26

04 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