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

[ruby-core:124833] [Ruby Bug#21882] IO::Buffer#locked leaves the buffer locked when the block raises
by hanazuki (Kasumi Hanazuki) 13 Jun '26

13 Jun '26

Issue #21882 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21882: IO::Buffer#locked leaves the buffer locked when the block raises https://bugs.ruby-lang.org/issues/21882 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `IO::Buffer#locked` should unlock the buffer even after the block raises an exception. ```ruby buf = IO::Buffer.new(100) buf.locked { fail } rescue nil buf.locked { p :ok } # expected to print :ok, but actually raises a LockedError ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125276] [Ruby Bug#22003] .bundle extensions not built when doing out-of-source build
by Kulikjak (Jakub Kulik) 13 Jun '26

13 Jun '26

Issue #22003 has been reported by Kulikjak (Jakub Kulik). ---------------------------------------- Bug #22003: .bundle extensions not built when doing out-of-source build https://bugs.ruby-lang.org/issues/22003 * Author: Kulikjak (Jakub Kulik) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [amd64-solaris2.11] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi, I encountered a pretty edge case extension build bug. When building Ruby out-of-source and executing the configure script with a full path in a workspace that contains "test" in its name, it fails to build all the extensions in the `.bundle/gems` directory. It can be easily reporoduced with the following: ``` > pwd /builds/testing/components/ruby/ruby-40 > mkdir build > cd build > /builds/testing/components/ruby/ruby-40/ruby-4.0.2/configure ... > /usr/gnu/bin/make -j 20 ... <the stuff in the .bundle directory is not built> ``` When doing it this way, the `srcdir` variable in the Makefile will be an absolute path, which is then used in `ext/configure-ext.mk` target and in `configure-ext.mk.tmpl` `Dir.glob` call, where the following line: ``` % next if extconf.any?{|f| f.include?(".bundle/gems") && f.include?("test") } ``` makes it omit all the extensions in the ".bundle/gems" directory. The problem is not there when I use a relative path (`../ruby-4.0.2/configure`) or when building directly in `ruby-4.0.2` (because the `srcdir` is relative in those cases). -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125751] [Ruby Bug#22002] argument stack underflow (-1)
by nagachika (Tomoyuki Chikanaga) 13 Jun '26

13 Jun '26

Issue #22002 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: DONTNEED, 3.4: REQUIRED, 4.0: DONE to 3.3: DONTNEED, 3.4: DONE, 4.0: DONE ruby_3_4 commit:f83274ef580b455c2980de5f205e515c41752696 merged revision(s) commit:d077df24a2256d760cc534b242b28822d4ef6376. ---------------------------------------- Bug #22002: argument stack underflow (-1) https://bugs.ruby-lang.org/issues/22002#change-117638 * Author: Anonymous * Status: Closed * Assignee: prism * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: DONE, 4.0: DONE ---------------------------------------- The following lines of code: ```ruby sleep(0.1) until defined?(@variable) @variable ``` produce this error: ``` home@My-Air testing % bundle exec ruby test.rb -- raw disasm-------- trace: 1 0000 jump <L000> ( 1) <L004> [sp: 0, unremovable: 1, refcnt: 1] 0002 putnil ( 1) <L005> [sp: 1, unremovable: 0, refcnt: 1] 0003 pop ( 1) 0004 jump <L000> ( 1) <L001> [sp: 0, unremovable: 1, refcnt: 5] 0006 putself ( 1) 0007 putobject 0.1 ( 1) 0009 opt_send_without_block <calldata:sleep, 1> ( 1) 0011 pop ( 1) <L000> [sp: 0, unremovable: 0, refcnt: 2] <L012> [sp: 0, unremovable: 0, refcnt: 0] * 0012 branchunless <L001> ( 1) adjust: [label: 4] 0014 putnil ( 1) <L002> [sp: -1, unremovable: 0, refcnt: 4] 0015 pop ( 1) trace: 1 0016 getinstancevariable :@variable, <ivc:0> ( 3) 0019 leave ( 3) --------------------- test.rb:1: argument stack underflow (-1) test.rb: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125553] [Ruby Bug#22076] defined? returns nil for protected methods defined in a module even when callable
by sampokuokkanen (Sampo Kuokkanen) 13 Jun '26

13 Jun '26

Issue #22076 has been reported by sampokuokkanen (Sampo Kuokkanen). ---------------------------------------- Bug #22076: defined? returns nil for protected methods defined in a module even when callable https://bugs.ruby-lang.org/issues/22076 * Author: sampokuokkanen (Sampo Kuokkanen) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Filing this to confirm whether defined? should return "method" here (matching the call check), or whether the current nil behavior is intentional. ### Summary `defined?` returns `nil` for a protected method defined in a module, even when the same call succeeds. For a protected method defined in a class, `defined?` and the call agree. ### Reproduction ~~~ruby module Mix def secret; 42; end protected :secret end class A; include Mix; end class B include Mix def call_it(other) = other.secret def defined_it(other) = defined?(other.secret) end p B.new.call_it(A.new) # => 42 p B.new.defined_it(A.new) # => nil (expected "method") ~~~ The class-defined version returns `"method"` for the same shape: ~~~ruby class Base def secret; 42; end protected :secret end class A < Base; end class B < Base def defined_it(other) = defined?(other.secret) end p B.new.defined_it(A.new) # => "method" ~~~ ### Fix Use `rb_callable_method_entry_with_refinements` and the existing `vm_defined_class_for_protected_call` helper. Patch with test: (will update soon) ## Environment - MacOS Tahoe 26.2 - Ruby master (HEAD) - ruby 4.0.1 -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125543] [Ruby Bug#22074] YJIT misaligns locals when there are > 256 local variables
by ibrahima (Ibrahim Awwal) 13 Jun '26

13 Jun '26

Issue #22074 has been reported by ibrahima (Ibrahim Awwal). ---------------------------------------- Bug #22074: YJIT misaligns locals when there are > 256 local variables https://bugs.ruby-lang.org/issues/22074 * Author: ibrahima (Ibrahim Awwal) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! We ran into this issue in production with a large Slim template in a Rails app, but we found that it's reproducible in any function with a lot of local variables. It seems like YJIT tracks local variables for register allocation in an 8-bit integer, so if there are more than 256 local variables in a function, the index overflows and maps back to the wrong variable and causes issues. We reproduced the issue with the released version of Ruby 4.0.4. We have a simple reproduction script and a proposed patch. The reproduction script generates some code with 257 locals and tests that it behaves correctly over multiple iterations (to exercise YJIT since it doesn't kick in right away). Full disclosure, the code is AI-written, and I don't know Rust, but I do know C and integer overflows, and it seems somewhat reasonable - though I'm not sure if it's the exact right fix. With YJIT disabled: ``` $ ruby yjit_many_locals_simple_repro.rb ruby=ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] yjit=false iterations=100000 YJIT is not enabled. Re-run with: ruby --yjit yjit_many_locals_simple_repro.rb iteration=10000 iteration=20000 iteration=30000 iteration=40000 iteration=50000 iteration=60000 iteration=70000 iteration=80000 iteration=90000 iteration=100000 ok iterations=100000 ``` With YJIT enabled ``` $ ruby --yjit yjit_many_locals_simple_repro.rb ruby=ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +YJIT +PRISM [x86_64-linux] yjit=true iterations=100000 failed_at=30 yjit_many_locals_simple_repro.rb:259:in 'Object#many_locals': undefined method '+' for an instance of Object (NoMethodError) from yjit_many_locals_simple_repro.rb:42:in 'block in <main>' from yjit_many_locals_simple_repro.rb:41:in 'Integer#times' from yjit_many_locals_simple_repro.rb:41:in '<main>' yjit_many_locals_simple_repro.rb:259:in 'Object#many_locals': undefined method '+' for an instance of Object (NoMethodError) from yjit_many_locals_simple_repro.rb:42:in 'block in <main>' from yjit_many_locals_simple_repro.rb:41:in 'Integer#times' from yjit_many_locals_simple_repro.rb:41:in '<main>' ``` Thank you for your consideration! ---Files-------------------------------- yjit_many_locals_simple_repro.rb (1.32 KB) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:125565] [Ruby Bug#22079] Float#ceil gives incorrect result
by cryptogopher (crypto gopher) 13 Jun '26

13 Jun '26

Issue #22079 has been reported by cryptogopher (crypto gopher). ---------------------------------------- Bug #22079: Float#ceil gives incorrect result https://bugs.ruby-lang.org/issues/22079 * Author: cryptogopher (crypto gopher) * Status: Open * ruby -v: ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Let's take following number as an example: ``` ruby > Float::MIN => 2.2250738585072014e-308 ``` This gives proper result: ```ruby > Float::MIN.ceil(308) => 2.9999999999999997e-308 ``` But this does not: ```ruby > Float::MIN.floor(309) => NaN ``` even though the result is perfectly valid `Float` number: ```ruby > "2.3e-308".to_f => 2.3e-308 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125215] [Ruby Bug#21986] RubyVM::AST incorrect location for literals followed by modifier `if`
by kddnewton (Kevin Newton) 13 Jun '26

13 Jun '26

Issue #21986 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21986: RubyVM::AST incorrect location for literals followed by modifier `if` https://bugs.ruby-lang.org/issues/21986 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` irb(main):001> RubyVM::AbstractSyntaxTree.parse("1.0if true") => (SCOPE@1:0-1:10 tbl: [] args: nil body: (IF@1:0-1:10 (TRUE@1:6-1:10) (FLOAT@1:3-1:3 1.0) nil)) irb(main):002> RubyVM::AbstractSyntaxTree.parse("1if true") => (SCOPE@1:0-1:8 tbl: [] args: nil body: (IF@1:0-1:8 (TRUE@1:4-1:8) (INTEGER@1:1-1:1 1) nil)) irb(main):003> ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125124] [Ruby Bug#21964] Fiber stack acquire can expand unnecessarily.
by ioquatix (Samuel Williams) 13 Jun '26

13 Jun '26

Issue #21964 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21964: Fiber stack acquire can expand unnecessarily. https://bugs.ruby-lang.org/issues/21964 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- In several common scenarios, the fiber stack allocator can choose to expand the fiber stack pool even when there are unreachable (effectively dead) fibers. For example, the following program will eventually crash if GC does not run in time: ```ruby loop do Fiber.new{Fiber.yield}.resume end ``` We have a loop that resumes a fiber, that fiber yields, and then becomes unreachable. Eventually, we will exhaust the OS vm map limit and fail with `FiberError`. However, at most only one fiber (stack) is needed to execute the above program, since the fiber immediately becomes unreachable. To fix this, we run GC before trying to expand the fiber stacks. In practice, fiber stacks are expanded on power of 2, up to 1024 fibers per allocation. So GC is only run in scenarios where we hit this limit. If GC is running normally, or fibers are terminating normally, we may never hit this code path. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123484] [Ruby Bug#21640] Core Pathname is missing 3 methods / is partially-defined
by Eregon (Benoit Daloze) 13 Jun '26

13 Jun '26

Issue #21640 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21640: Core Pathname is missing 3 methods / is partially-defined https://bugs.ruby-lang.org/issues/21640 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > core_pathname_methods.txt $ ruby -rpathname -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > require_pathname_methods.txt $ diff core_pathname_methods.txt require_pathname_methods.txt 36a37 > find 72a74 > rmtree 98a101 > mktmpdir ``` So `#find`, `#rmtree` and `.mktmpdir` are missing from core Pathname. And indeed, they give NoMethodError, e.g. ``` $ ruby -ve 'Pathname.new("doesnotexist").rmtree' ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] -e:1:in '<main>': undefined method 'rmtree' for an instance of Pathname (NoMethodError) ``` I think this is confusing and unexpected for most users. Either Pathname should be fully defined or not at all, having a partially-defined Pathname seems particularly confusing (a bit like an autoload that failed in the middle or so). AFAIK the only core class which used to have this was Fiber with `alive?` and `transfer`, that certainly caused its share of confusion, and Fiber has since been fixed, now even without `require "fiber"` Fiber has all methods. Furthermore these 3 methods are not documented as needing `require 'pathname'` in their documentation: https://github.com/ruby/ruby/blob/master/lib/pathname.rb The reason these 3 methods are not in core pathname seems to be (from [this comment](https://github.com/ruby/pathname/issues/64#issuecomment-3388907046)) > That's consensus with akr and me. We should avoid loading other libraries by simply calling methods from the embedded core classes. I understand that concern and I share it, but I think the situation of having a partially-defined Pathname in core is quite problematic. I think there are 2 solutions: * Define all Pathname methods in core. The `require` are done lazily inside the methods so AFAIK there is no technical issue blocking that, but it's not ideal design-wise that a core class can load default gems (i.e. give up that concern for this particular case). * Do not define Pathname in core and let it be a default gem as it was in Ruby 3.4. I discuss the second in more details, because I found more problems than I would have imagined with core Pathname: ## Should Pathname be in core? #17473 proposed to make Pathname core. That sounded great to me at first thought, but as I realize the practical problems with it I'm thinking it's actually better to keep Pathname non-core and as a default gems. Here are concerns with having Pathname in core: 1. Pathname inherently depends on other default gems/stdlib like `find`, `fileutils` and `tmpdir`. This is important to make Pathname useful. The docs even phrase it like this: `ri Pathname` > ... > All functionality from File, FileTest, and some from Dir and > FileUtils is included, in an unsurprising way. It is essentially a > facade for all of these, and more. 2. core Pathname is missing 3 methods compared to gem Pathname (shown above) 3. the pathname gem is likely to gain extra features, methods and bug fixes. For example I see [4 PRs](https://github.com/ruby/pathname/pulls) adding new methods. It means core Pathname will always be outdated and potentially missing some new methods. 4. One can still use the pathname gem even if it's in core, but surprisingly just `require 'pathname'` is not enough: ``` $ gem install pathname Building native extensions. This could take a while... Successfully installed pathname-0.4.0 1 gem installed $ ruby -e 'require "pathname"; puts $".grep(/pathname/)' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb ^ wrong that's the stdlib pathname $ ruby -e 'gem "pathname"; require "pathname"; puts $".grep(/pathname/)' # some warnings, reported in https://github.com/ruby/pathname/issues/66 pathname.so /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/pathname-0.4.0/lib/pathname.rb ^ correct ``` This is another source of confusion caused by core pathname. It even happens with Bundler! ``` $ cat Gemfile source "https://rubygems.org" gem "pathname" $ bundle install $ ruby -e 'require "bundler/setup"; require "pathname"; puts $".grep(/pathname/); puts; puts $:' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/gems/pathname-0.4.0/lib /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/extensions/x86_64-linux/3.5.0+4-static/pathname-0.4.0 /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/bundler-2.8.0.dev/lib /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/site_ruby /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/x86_64-linux $ bundle exec ruby -e 'require "pathname"; puts $".grep(/pathname/); puts; puts $:' same as above ``` I'm not sure why, but that seems a serious bug that the `pathname` gem apparently can't be used at all with Bundler. 4. due to this difference in terms of methods for core & gem pathname it seems complicated to keep core Pathname and gem Pathname in sync, since e.g. everything is naturally in one `.rb` file in the gem, but in two `.rb` files in core 5. the pathname gem has to `remove_const :Pathname` to avoid conflicts and warnings in https://github.com/ruby/pathname/blob/4689b0b78d081ae855f325e086d95803fa5bd…. This is bad for Ruby JITs, especially if core Pathname methods might have been used, as it will invalidate JITs compilations, invalidate some inline caches (also bad for the interpreter), caused the JIT to do more compilations which means slower warmup, makes it much harder to persist JITed code across process executions, etc. Based on all of these I think it would actually be better to not have Pathname in core, and let it be a default gem. Having to `require "pathname"` as one always needed to do so far seems far better than a partially-defined core Pathname with rough edge cases (those concerns). -- https://bugs.ruby-lang.org/

8 25

[ruby-core:125728] [Ruby Bug#22109] Unexpected or misleading error when subclass of a ractor calls a new method on itself
by miles-georgi (Miles Georgi) 13 Jun '26

13 Jun '26

Issue #22109 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22109: Unexpected or misleading error when subclass of a ractor calls a new method on itself https://bugs.ruby-lang.org/issues/22109 * 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 ---------------------------------------- Hey hey! When I run the following code: ```ruby class SubRactor < Ractor attr_accessor :foo end SubRactor.new { puts foo }.join ``` I get the following error: ``` can not access instance variables of shareable objects from non-main Ractors (Ractor::IsolationError) ``` Unclear if I shouldn't get an error of any sort in this situation, but if this is a legitimate error situation, this error seems inaccurate since Ractors can obviously access instance variables of shareable objects. A tiny script that shows that: ```ruby class C attr_accessor :foo def initialize = self.foo = 100 INSTANCE = new.freeze end raise "not shareable!" unless Ractor.shareable?(C::INSTANCE) Ractor.new { puts C::INSTANCE.foo }.join ``` This prints out 100 as expected instead of giving that error. This happens on both: ruby 4.1.0dev (2026-06-11T14:25:18Z master 8e8682fc23) +PRISM [x86_64-linux] and ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] The script is so puny seems I shouldn't upload the file but let me know if I should just always upload a script file when filing these even when they are trivially small. Cheers! -- https://bugs.ruby-lang.org/

3 5