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

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 11 Oct '25

11 Oct '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:122558] [Ruby Bug#21446] StackOverflow when changing visibility in reopened refinement
by luke-gru (Luke Gruber) 11 Oct '25

11 Oct '25

Issue #21446 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21446: StackOverflow when changing visibility in reopened refinement https://bugs.ruby-lang.org/issues/21446 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby class A def a :a end end class B < A end module R refine B do private :a end end module R refine B do public :a end end using R B.new.a # StackOverflow ``` I would expect it to change the visibility, not to overflow the stack. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123318] [Ruby Bug#21614] thread_sched_wait_events race with timer_thread_wakeup
by luke-gru (Luke Gruber) 09 Oct '25

09 Oct '25

Issue #21614 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21614: thread_sched_wait_events race with timer_thread_wakeup https://bugs.ruby-lang.org/issues/21614 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `thread_sched_wait_events` checks th->sched.waiting_reason.flags under thread_sched_lock but not under timer_thread.waiting_lock. The timer thread sets it under the timer_thread.waiting_lock only. This race results in the assertion failure: `../ruby/thread_pthread.c:909: Assertion Failed: thread_sched_to_running_common:sched->running != th` Reproduction script (run it many times): ```ruby require "timeout" def invoke_ruby(args, stdin_data = "", capture_stdout = false, capture_stderr = false, encoding: nil, timeout: 10, reprieve: 1, timeout_error: Timeout::Error, stdout_filter: nil, stderr_filter: nil, ios: nil, signal: :TERM, rubybin: "ruby", precommand: nil, **opt) timeout = 60 in_c, in_p = IO.pipe out_p, out_c = IO.pipe if capture_stdout err_p, err_c = IO.pipe if capture_stderr && capture_stderr != :merge_to_stdout opt[:in] = in_c opt[:out] = out_c if capture_stdout opt[:err] = capture_stderr == :merge_to_stdout ? out_c : err_c if capture_stderr if encoding out_p.set_encoding(encoding) if out_p err_p.set_encoding(encoding) if err_p end ios.each {|i, o = i|opt[i] = o} if ios c = "C" child_env = {} if Array === args and Hash === args.first child_env.update(args.shift) end args = [args] if args.kind_of?(String) # use the same parser as current ruby if args.none? { |arg| arg.start_with?("--parser=") } args = ["--parser=prism"] + args end pid = spawn(child_env, *precommand, rubybin, *args, opt) in_c.close out_c&.close out_c = nil err_c&.close err_c = nil if block_given? return yield in_p, out_p, err_p, pid else th_stdout = Thread.new { out_p.read } if capture_stdout th_stderr = Thread.new { err_p.read } if capture_stderr && capture_stderr != :merge_to_stdout in_p.write stdin_data.to_str unless stdin_data.empty? in_p.close if (!th_stdout || th_stdout.join(timeout)) && (!th_stderr || th_stderr.join(timeout)) timeout_error = nil else $stderr.puts "Error: timed out" status = terminate(pid, signal, opt[:pgroup]) terminated = Time.now end stdout = th_stdout.value if capture_stdout stderr = th_stderr.value if capture_stderr && capture_stderr != :merge_to_stdout out_p.close if capture_stdout err_p.close if capture_stderr && capture_stderr != :merge_to_stdout status ||= Process.wait2(pid)[1] stdout = stdout_filter.call(stdout) if stdout_filter stderr = stderr_filter.call(stderr) if stderr_filter if timeout_error bt = caller_locations msg = "execution of #{bt.shift.label} expired timeout (#{timeout} sec)" raise timeout_error, msg, bt.map(&:to_s) end return stdout, stderr, status end ensure [th_stdout, th_stderr].each do |th| th.kill if th end [in_c, in_p, out_c, out_p, err_c, err_p].each do |io| io&.close end [th_stdout, th_stderr].each do |th| th.join if th end end def terminate(pid, signal = :TERM, pgroup = nil) case pgroup when 0, true pgroup = -pid when nil, false pgroup = pid end begin Process.kill signal, pgroup rescue Errno::EINVAL rescue Errno::ESRCH end $? end rs = [] 100.times do rs << Ractor.new do script = '$stdout.sync=true; def rec; print "."; rec; end; Fiber.new{rec}.resume' invoke_ruby([{}, '-e', script], "", true, true) end end rs.each(&:join) ``` This script is just taken directly from a failed test in the test suite that was run under multiple ractors at once (`test_vm_stack_size`). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 09 Oct '25

09 Oct '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 08 Oct '25

08 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 13

[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:123288] [Ruby Bug#21610] Use ec->interrupt_mask to prevent interrupts.
by ioquatix (Samuel Williams) 05 Oct '25

05 Oct '25

Issue #21610 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21610: Use ec->interrupt_mask to prevent interrupts. https://bugs.ruby-lang.org/issues/21610 * Author: ioquatix (Samuel Williams) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program can trigger `rb_bug` in `rb_fiber_scheduler_unblock`: ```ruby require 'async/scheduler' scheduler = Async::Scheduler.new Fiber.set_scheduler(scheduler) Signal.trap(:USR1) do end q = Thread::Queue.new Thread.new do loop do Ractor.new do Process.kill(:USR1, $$) end.join end end Fiber.schedule do Fiber.schedule do 1.upto(1000000) do |i| sleep 0.01 q.pop q.push(1) puts "1 iter push/pop" end end Fiber.schedule do 1.upto(1000000) do |i| sleep 0.01 q.push(i) q.pop puts "1 iter push/pop#2" end end Fiber.schedule do gets exit! end end ``` In brief, when `rb_fiber_scheduler_unblock` executes with `ec->interrupt_flag` set, the following sequence can occur: ``` Thread A (Signaling) Thread B (Blocked Fiber) -------------------- --------------------- calls unblock(fiber_x) ├─ enters scheduler user code fiber_x sleeping in scheduler.block() ├─ ⚠️ SIGNAL INTERRUPT ⚠️ ├─ raises SignalException ├─ unblock operation aborted ├─ scheduler state inconsistent └─ returns believing success └─ fiber_x waits forever ⚠️ ``` Confirmed fix: https://github.com/ruby/ruby/pull/14588 -- https://bugs.ruby-lang.org/

2 6

[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