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

[ruby-core:119895] [Ruby master Bug#20889] IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position
by javanthropus (Jeremy Bopp) 13 Nov '25

13 Nov '25

Issue #20889 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20889: IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position https://bugs.ruby-lang.org/issues/20889 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetbyte(93) f.pos # => -1; negative value is surprising! end Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-8')) f.pos # => -1; similar to the ungetbyte case end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) f.pos # => 0; maybe should be -2 to match the previous ungetc case? end ``` It doesn't seem logical that `IO#pos` should ever be affected by `IO#ungetc` or `IO#ungetbyte`. The pushed characters or bytes aren't really in the stream source. The value of `IO#pos` implies that jumping directly to that position via `IO#seek` and reading from there would return the same character or byte that was pushed, but the pushed characters or bytes are lost when the operation to seek in the stream is performed. In the case where `IO#pos` is a negative value, attempting to seek to that position actually raises an exception. In the `IO#ungetc` with character conversion case above, it seems unreasonable to make `IO#pos` report an even less correct position. In that case, the position would need to be adjusted by 2 bytes in reverse due to the internal encoding of the stream, but that is completely inconsistent with the behavior of `IO#pos` when reading from the stream normally where it reports the underlying stream's byte position and not the number of transcoded bytes that have been read: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc.bytesize # => 2; due to the internal encoding of the stream f.pos # => 1; reports actual bytes read from the stream, not transcoded bytes end ``` Attempting to use `IO#pos` when there are characters or bytes pushed into the read buffer by way of `IO#ungetc` or `IO#ungetbyte` should result in one of the following behaviors: 1. Raise and exception 2. Return the stream's position, clearing the read buffer entirely 3. Return the stream's position, ignoring the pushed characters or bytes, and produce a warning -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122343] [Ruby Misc#21385] Namespace: Suggesting a rename
by fxn (Xavier Noria) 10 Nov '25

10 Nov '25

Issue #21385 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21385: Namespace: Suggesting a rename https://bugs.ruby-lang.org/issues/21385 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- I'd like to suggest a rename of namespaces. The word "namespace" is already taken in Ruby. We say that classes and modules act as or represent. Constant paths nest them in practice. We say that it is a best practice that gems create their own namespace, etc. If the feature goes ahead with this name, the above sentences, well-established in the Ruby community, will start to sound confusing, because that meaning of "namespace" stays. If you look at the index in Matz's book, "namespaces" is indexed in pages 248–250. Title of section 7.5.1 is "Modules as Namespaces". Besides, I have had a few experiences explaining the proposal to people, and quickly realizing they assume this is something like C++ namespaces or Java packages. Then, I have to undo that mental model and start all over saying "forget that mental model". Those are like our constant paths, only more simple and strict. I think it may also be confusing in this sense (though this could be OK if it wasn't for the previous point.) To be constructive: Some alternative names that I have thought about are "isolates", "shields", or "cells". ("sandboxes" is close, but may have security connotations you do not want to suggest.) -- https://bugs.ruby-lang.org/

18 32

[ruby-core:118243] [Ruby master Feature#20564] Switch default parser to Prism
by kddnewton (Kevin Newton) 22 Oct '25

22 Oct '25

Issue #20564 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20564: Switch default parser to Prism https://bugs.ruby-lang.org/issues/20564 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- This issue is to propose switching the default parser for Ruby to Prism on the master branch. The main goal is to get this default into both master and the next preview so that the community has plenty of time to test before the eventual 3.4 release. Matz has indicated that the final decision about the default parser for Ruby 3.4 will be made later in the year. Decisions about the default parser for Ruby 3.5+ and the relationship between Prism, lrama, parse.y, etc. will also be made at a later time. ## Background For some background on the Prism project itself, here are a couple of links in chronological order that you can read: * https://bugs.ruby-lang.org/issues/19741 * https://railsatscale.com/2023-06-12-rewriting-the-ruby-parser/ * https://kddnewton.com/2024/01/23/prism.html * https://railsatscale.com/2024-04-16-prism-in-2024/ ## Status Prism now passes all Ruby tests and specs. Internally at Shopify, it also passes our Core monolith's CI, which is a large and complex Rails application. We are confident that it is ready for production use. External to CRuby, Prism has already been adopted extensively around the ecosystem, including but not limited to: * [JRuby](https://github.com/jruby/jruby/pull/8103) (via Java) * [TruffleRuby](https://github.com/oracle/truffleruby/issues/3117) (via Java) * [Natalie](https://github.com/natalie-lang/natalie/pull/1213) (via C++ and Ruby) * [Opal](https://github.com/opal/opal/pull/2642) (via Ruby and WASM) * [repl_type_completor](https://github.com/ruby/repl_type_completor) * [rubocop](https://docs.rubocop.org/rubocop/configuration.html#setting-the-pa… (via parser translator) * [ruby-lsp](https://github.com/Shopify/ruby-lsp) * [packwerk](https://github.com/Shopify/packwerk/pull/388) (via parser translator) Fortunately with the community adoption, we have been able to find many edge cases and bugs that have been fixed. Thank you so much to everyone who has tried, used, reported problems with, and improved Prism in the last couple of years. We would not have hit this milestone without this community involvement. ## Caveats While Prism correctly accepts and parses all valid Ruby syntax, there are still a number of cases where it does not reject invalid syntax as it should. We are currently working on these cases, and we are confident that we can eliminate them before the next preview release. You can find them listed here: https://github.com/ruby/prism/issues?q=is%3Aopen+is%3Aissue+label%3Ainvalid…. This is our top priority right now, and I anticipate these being resolved quickly. The other caveat is unknown unknowns: bugs or syntax issues that we have yet to discover. At Shopify we are currently taking numerous steps to mitigate this risk, including: * Prism currently passes all Ruby tests and specs, and will continue to going forward. The tests and specs are extensive, and we are confident this gets us almost all of the way there. * Grammar-based fuzzing to ensure we handle all possible syntax variations (both valid and invalid). As an example, that recently led to the discovery that the current compiler was segfaulting on safe navigation in for loops (https://bugs.ruby-lang.org/issues/20468) It has also found several memory leaks that have been fixed. * Mutation testing of existing source files (by adding and deleting random bytes) to find additional edge cases. Our goal is 100% compatibility, and we believe this is achievable through the above techniques and others. The goal of this proposal is to allow more companies to test their codebase against Prism, and to make this easier. We believe that we can sort out the remaining problems much more quickly in that manner. ## Implementation The implementation will be relatively straightforward, as there is already the `--parser` flag that can be used to switch between the current parser and Prism. We will change the default to be `"prism"` instead of `"parse.y"`. There is no plan to remove or change any code related to `parse.y`, `lrama`, or `compile.c` at this time, as we want to create the minimal amount of change possible to ensure stability. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 18 Oct '25

18 Oct '25

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

6 12

[ruby-core:122164] [Ruby Feature#21347] Add `open_timeout` as an overall timeout option for `Socket.tcp`
by shioimm (Misaki Shioi) 07 Oct '25

07 Oct '25

Issue #21347 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #21347: Add `open_timeout` as an overall timeout option for `Socket.tcp` https://bugs.ruby-lang.org/issues/21347 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- I propose to add an overall timeout option to `Socket.tcp` (and `TCPSocket.new`) ### Background Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options: - `resolv_timeout`, which controls the timeout for DNS resolution - `connect_timeout`, which controls the timeout for the connection attempt With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized. As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap. Example: When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set: 1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved). 2. A connection attempt is initiated to the IPv6 address 3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues. 4. After 200ms from the start, the method raises a `resolv_timeout` error. In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms). Furthermore, in HEv2, connection attempts are also parallelized. It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted. Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured. Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout. Example: When `connect_timeout: 100ms` is set and 3 address candidates: 1. Connect to address `a` at t=0ms. 2. Connect to address `b` at t=250ms. 3. Connect to address `c` at t=500ms. 4. If all fail, the exception is raised at t=1500ms (1000ms after `c`, 1250ms after `b`, 1500ms after `a`). 1. Start a connection attempt to the address `a` 2. 250ms after step 1, start a new connection attempt to the address `b` 3. 500ms after step 1, start a new connection attempt to the address `c` 4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about. These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout. ### Proposal I propose adding an `open_timeout` option to `Socket.tcp` in the following PR, which triggers a timeout after a specified duration has elapsed from the start of the method. https://github.com/ruby/ruby/pull/13368 The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`. If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases. If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`. While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout. ### Outcome If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`. https://github.com/ruby/ruby/blob/aa0f689bf45352c4a592e7f1a044912c40435266/… -- https://bugs.ruby-lang.org/

3 8

[ruby-core:112552] [Ruby master Bug#19461] Time.local performance tanks in forked process (on macOS only?)
by ioquatix (Samuel Williams) 06 Oct '25

06 Oct '25

Issue #19461 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19461: Time.local performance tanks in forked process (on macOS only?) https://bugs.ruby-lang.org/issues/19461 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following program demonstrates a performance regression in forked child processes when invoking `Time.local`: ```ruby require 'benchmark' require 'time' def sir_local_alot result = Benchmark.measure do 10_000.times do tm = ::Time.local(2023) end end $stderr.puts result end sir_local_alot pid = fork do sir_local_alot end Process.wait(pid) ``` On Linux the performance is similar, but on macOS, the performance is over 100x worse on my M1 laptop. -- https://bugs.ruby-lang.org/

5 10

[ruby-core:116946] [Ruby master Bug#20302] Multiple refinements cannot be applied to the same module
by mame (Yusuke Endoh) 06 Oct '25

06 Oct '25

Issue #20302 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20302: Multiple refinements cannot be applied to the same module https://bugs.ruby-lang.org/issues/20302 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: shugo (Shugo Maeda) * ruby -v: ruby 3.4.0dev (2024-02-20T07:17:20Z master a605234bfa) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If we are using multiple refinements for the Kernel module, it seems that only the last refinement is enabled. In the following example, we can call `f2` of M2, which is enabled later. but cannot call `f1` of M1. ```ruby module M1 refine(Kernel) do def f1 = :f1 end end module M2 refine(Kernel) do def f2 = :f2 end end class Foo using M1 using M2 def test p f2 #=> :f2 p f1 # expected => :f1 # actual => undefined local variable or method 'f1' for an instance of Foo end end Foo.new.test ``` Note that if I change `refine(Kernel)` to `refine(Object)`, it works as expected. So I think there is a problem only when the refinement target is a module. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122121] [Ruby Bug#21342] Segfault: invalid keeping_mutexes when using Mutex in Thread then Fiber after GC
by maciej.mensfeld (Maciej Mensfeld) 05 Oct '25

05 Oct '25

Issue #21342 has been reported by maciej.mensfeld (Maciej Mensfeld). ---------------------------------------- Bug #21342: Segfault: invalid keeping_mutexes when using Mutex in Thread then Fiber after GC https://bugs.ruby-lang.org/issues/21342 * Author: maciej.mensfeld (Maciej Mensfeld) * Status: Open * ruby -v: 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby crashes with a `[BUG] invalid keeping_mutexes error` when attempting to GC locked mutex that was used in a Thread within a Fiber context after garbage collection. The error indicates an attempt to unlock a mutex that is not locked, suggesting a state management issue with mutexes across Thread and Fiber boundaries. ## Ruby Version `ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux]` ## Reproduce Process ``` ruby # segv.rb 5.times do m = Mutex.new Thread.new do m.synchronize do end end.join Fiber.new do GC.start m.lock end.resume end ``` 1. Save the above code to a file (e.g., `segv.rb`) 2. Run with `ruby segv.rb` 3. The crash occurs intermittently - sometimes it crashes immediately, sometimes it hangs, once in a while it works ## Actual Result The program crashes with the following error: ``` segv.rb: [BUG] invalid keeping_mutexes: Attempt to unlock a mutex which is not locked ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] ``` whole segfault in the attached txt file. Full crash backtrace shows the error originates from: - `rb_threadptr_unlock_all_locking_mutexes` in thread.c:450 - `rb_thread_terminate_all` in thread.c:467 The crash suggests an issue in mutex state management during thread termination. ## Expected Result The script should complete successfully without crashing. The mutex should be properly managed across Thread and Fiber contexts, and garbage collection should not interfere with mutex state. ---Files-------------------------------- crash.txt (23.4 KB) -- https://bugs.ruby-lang.org/

7 10

[ruby-core:115552] [Ruby master Misc#20032] Propose @kjtsanaktsidis as a commiter
by jeremyevans0 (Jeremy Evans) 26 Sep '25

26 Sep '25

Issue #20032 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Misc #20032: Propose @kjtsanaktsidis as a commiter https://bugs.ruby-lang.org/issues/20032 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I'd like to propose @kjtsanaktsidis as a committer, with a focus on bug triaging and fixing. During RubyKaigi 2023, KJ expressed interest in helping triage and fix bugs, and since then, he has fixed numerous bugs. What's most impressive about KJ's contributions is the difficulty of the bugs he has fixed, and the wide range of areas in which he has fixed bugs (GC, threading, FreeBSD support, ractors, rubygems, extensions, tests, old bugs, etc.). Here is a list of bugs KJ has fixed: * #20021 * #19994 * #19928 * #19873 * #19387 * #19680 * #4173 Here is a list of open pull requests submitted by KJ to fix bugs: * #20022 https://github.com/ruby/ruby/pull/9041 * #19991 https://github.com/ruby/ruby/pull/8949 and https://github.com/ruby/ruby/pull/8856 * #20001 https://github.com/ruby/ruby/pull/8903 * #19717 https://github.com/ruby/ruby/pull/8331 * #19144 https://github.com/ruby/ruby/pull/7295 * #18795 https://github.com/ruby/ruby/pull/5992 In addition to these Redmine issues, KJ has also fixed other bugs: * https://github.com/ruby/ruby/commit/9a62fd3cbae2ebb60e2f9cad782af1ad18db4319 * https://github.com/ruby/ruby/commit/76dc327eeffefe02577999fe5f8215f762a581b6 * https://github.com/ruby/ruby/commit/082962e857833dfc16881cb4dfb44caa175590ba * https://github.com/ruby/ruby/commit/edee9b6a12ac846d7b3de2d704e170bf28178cb3 * https://github.com/ruby/ruby/commit/dd406c5a911d2f4a16ce97016666760713540185 * https://github.com/ruby/ruby/commit/7bd7aee02e303de27d2cddfc5ef47e612d6782cb * https://github.com/ruby/ruby/commit/05ffc037ad15560cb2c683682c5bc374156571d7 * https://github.com/ruby/ruby/pull/7867 * https://github.com/ruby/ruby/pull/7865 * https://github.com/ruby/zlib/commit/3b9fe962d8 * https://github.com/ruby/zlib/commit/c96e8b9a57 In addition to bug fixing, KJ has also proposed and implemented a useful Socket feature: * #19179 https://github.com/ruby/ruby/pull/6822 -- https://bugs.ruby-lang.org/

8 14

[ruby-core:122274] [Ruby Bug#21370] `it` can cause ISeq serialization failure
by byroot (Jean Boussier) 16 Sep '25

16 Sep '25

Issue #21370 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21370: `it` can cause ISeq serialization failure https://bugs.ruby-lang.org/issues/21370 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- Originally reported at: https://github.com/rails/rails/issues/55108 ```ruby iseq = RubyVM::InstructionSequence.compile(<<~'RUBY') [1].each do rescue => e puts it end RUBY iseq.to_binary # CRASH ``` ``` miniruby(sigsegv) (null):0 miniruby(RB_FL_ANY_RAW+0x20) [0x1010ac504] internal/fl_type.h:507 miniruby(rbimpl_rstring_getmem+0x20) [0x101090674] internal/core/rstring.h:393 miniruby(rb_str_cmp+0x4c) [0x10109920c] string.c:4541 miniruby(outer_variable_cmp+0x3c) [0x100e43b64] compile.c:13381 miniruby(cmp_bsd_qsort+0x3c) [0x1010fe810] util.c:239 miniruby(ruby_qsort+0x5c) [0x1010fe7a8] util.c:248 miniruby(ibf_dump_outer_variables+0x150) [0x100e43708] compile.c:13402 miniruby(ibf_dump_iseq_each+0x19c) [0x100e423cc] compile.c:13527 miniruby(ibf_dump_iseq_list_i+0x38) [0x100e420fc] compile.c:13862 miniruby(apply_functor+0x40) [0x10107bad8] st.c:1644 ``` It is crashing while trying to sort outer variables, and `it` is anonymous. -- https://bugs.ruby-lang.org/

2 6