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

[ruby-core:124187] [Ruby Bug#21779] Do not export functions from statically linked extensions
by nobu (Nobuyoshi Nakada) 24 Mar '26

24 Mar '26

Issue #21779 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21779: Do not export functions from statically linked extensions https://bugs.ruby-lang.org/issues/21779 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Reported at https://github.com/ruby/io-console/pull/105. This is caused by `InitVM_console` exposed from the statically linked io/console is called from the loaded io-console gem. The static `InitVM_console` initializes the ractor local storage key, but it is different from the key used in the gem extension. Also, [the workaround for conflict between `Init` functions](commit:ae8990aef098410ecc2b5f48fea9d7d171a3c5f6) is necessary for `InitVM` functions too. -- https://bugs.ruby-lang.org/

3 2

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

24 Mar '26

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/

5 4

[ruby-core:121642] [Ruby Bug#21266] YJIT GC safety crash with proc objects as block argument
by alanwu (Alan Wu) 23 Mar '26

23 Mar '26

Issue #21266 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21266: YJIT GC safety crash with proc objects as block argument https://bugs.ruby-lang.org/issues/21266 * Author: alanwu (Alan Wu) * Status: Open * Assignee: yjit * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby # Run with --yjit-call-threshold=1 def foo(args) = bar(*args, &proc { _1 }) def bar(_, _, _, _, *rest) = yield rest GC.stress = true foo([1,2,3,4]) foo([1,2,3,4]) ``` The proc in these calls get collected on the yield to the GC to allocate the rest parameter arary. ``` ../vm_core.h:1668: Assertion Failed: vm_block_handler_type:rb_obj_is_proc(block_handler) ``` Or in release builds: ``` ../test.rb:1: [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin24] -- C level backtrace information ------------------------------------------- /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_bugreport+0xb4c) [0x104595590] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1043d6120] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(sig_do_nothing+0x0) [0x1044fc4b0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x187572de4] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_invokeblock+0x144) [0x10456b004] ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124604] [Ruby Bug#21847] Backport `syntax_suggest` 2.0.3 to supported branches
by Earlopain (Earlopain _) 23 Mar '26

23 Mar '26

Issue #21847 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21847: Backport `syntax_suggest` 2.0.3 to supported branches https://bugs.ruby-lang.org/issues/21847 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Prism contains a translation layer for ripper, which until very recently didn't emit `on_sp` tokens. This has now been implemented to improve compatibility. However right after merging some `syntax_suggest` tests started failing: https://gist.github.com/schneems/834c75345b2085bda54dab69d913bcc0. `syntax_suggest` is using the ripper translation layer and is working around the missing `on_sp` tokens. Now that they are correctly created by prism, `syntax_suggest` is not able to handle these. For prism this is just a bugfix but I do not want to break `syntax_suggest` unnecessarily. I asked @schneems and this is what he had to say about it: https://github.com/ruby/syntax_suggest/pull/243#issuecomment-3779113958 Backport PRs: -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`
by ioquatix (Samuel Williams) 19 Mar '26

19 Mar '26

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

8 18

[ruby-core:124971] [Ruby Feature#21950] Add a built-in CPU-time profiler
by osyoyu (Daisuke Aritomo) 19 Mar '26

19 Mar '26

Issue #21950 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21950: Add a built-in CPU-time profiler https://bugs.ruby-lang.org/issues/21950 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- Modern CRuby workloads can consume CPU concurrently across multiple native threads, especially with multiple Ractors and C exts which release the GVL. I'd like to propose the idea of integrating a built-in CPU-time profiler CRuby to enable more accurate and stable profiling in such situations. ## Motivation & Background CPU profilers indicate how much CPU time were consumed by different methods. Most CPU-time profilers rely on the kernel to track consumed CPU time. `setitimer(3)` and `timer_create(3)` are APIs to configure kernel timers. The process receives a profiling signal (SIGPROF) every given time of CPU time consumed (e.g. 10 ms). In general, a profiler needs to know which _thread_ consumed how much CPU time to attribute work to the correct thread. This wasn't a real requirement for Ruby in the pre-Ractor age, since only one native thread could consume CPU time at any given moment due to GVL limitations. Using process-wide CPU-time timers provided by `setitimer()` effectively did the job. It was safe to assume that the active thread was doing some work using the CPU when a profiling signal arrived. Of course, this assumption does not stand in all situations. One is the case where C extensions release the GVL. Another is the multi-Ractor situation. In these cases, multiple native threads may simultaneously consume CPU time. Linux 2.6.12+ provides a per-thread timer to address this task. Profilers such as [Pf2](https://github.com/osyoyu/pf2) and [dd-trace-rb](https://github.com/DataDog/dd-trace-rb) use this feature to keep track of CPU time. However, utilizing this API requires information that CRuby does not necessarily expose. Both carry copies of CRuby headers in order to access internal structs such as `rb_thread_t`. This is quite fragile and possibly unsustainable in the age where CRuby evolves towards Ractors and M:N threading. ## Proposal Implement a built-in CPU-time profiler as `ext/profile`, and add some information extraction points to the VM built exclusively for it. ```ruby require 'profile' RubyVM::Profile.start # your code here RubyVM::Profile.stop #=> results ``` `ext/profile` will take care of the following in coordination with some VM helpers: - Tracking creation and destruction of native thread (NT) s - Management of kernel timers for those threads - i.e. calling `pthread_getcpuclockid(3)` and `timer_create(3)` - This will require iterating over all Ractors and shared NTs on profiler init - Handling of SIGPROF signals which those timers will generate - Walking the stack (calling `rb_profile_frames()`) - I'm not going to make this part of this ticket, but I'm thinking we can make `rb_profile_frames()` even more granular by following VM instructions, which is probably something we don't want to expose as an API We would need to add some APIs to the VM for `ext/profile`: - An API returning all alive NTs - Event hooks notifying creation and destruction of NTs - Event hooks notifying assign/unassign of RTs to NTs Since only Linux provides the full set of required kernel features, the initial implementation will be limited to Linux systems. I can expand support to other POSIX systems by employing `setitimer()` later, but they will receive limited granularity (process-level CPU-time timers). ### Output interface One thing to consider is the output format. I think we have a few practical choices here: - Adopt pprof's `profile.proto` format. - This is a widely accepted format across tools including visualizers. - The format itself is pretty flexible, so it shouldn't be hard to add custom fields. - Just return a Hash containing profile results. - We'd need to design some good format. ### Things out of scope - Visualization - Interaction with external visualizers / trackers / etc These can be better left to normal RubyGems. ### Why not an external gem? Through maintaining [Pf2](https://github.com/osyoyu/pf2), an CPU-time profiler library, I have encountered many difficulties obtaining information required for accurate profiling. The rule of thumb is that more internal information a profiler can access, the more accuracy it can achieve. However, from the CRuby maintenance perspective, I suppose not too many APIs exposing implementation details are wanted. Locating a profiler under `ext/` looks like nice middle ground. Placing core 'profiling' logic (sampler scheduling, sampling itself) in CRuby and abstracting it as 'RubyVM::Profile' should work cleanly. It should be noted that existing profilers have their own unique features, such as markers, unwinding of C stacks and integration with external APMs. I don't want to make this a tradeoff between accuracy and feature; instead, I'd like to design an API where both could live. ### Study on other languages A handful of VM-based languages carry profiler implementation in their runtime. - Go: runtime/pprof https://github.com/golang/go/tree/master/src/runtime/pprof - OpenJDK: JFR https://github.com/openjdk/jdk/tree/master/src/hotspot/share/jfr - Node.js: --cpu-prof https://nodejs.org/en/learn/getting-started/profiling - And more Among these, OpenJDK is a notable entry. JVM profilers have configured used `AsyncGetCallTrace()`, which is just like `rb_profile_frames()`, to obtain stack traces from signal handlers. The signal originates from kernel timers installed by the profilers, configured to fire every specified interval of CPU time (e.g. 10 ms). Even though `AsyncGetCallTrace()` and async-profiler (its primary user) are very sophisticated and battle-tested, JFR folks have decided to control sampling timing within the runtime to improve accuracy and stability. For more information on JVM, see: - [JEP 509](https://openjdk.org/jeps/509) - [JEP 518](https://openjdk.org/jeps/518) - [Taming the Bias: Unbiased* Safepoint-Based Stack Walking in JFR](https://mostlynerdless.de/blog/2025/05/20/taming-the-bias-unbiased-safepoint-based-stack-walking-in-jfr/) -- https://bugs.ruby-lang.org/

6 17

[ruby-core:125071] [Ruby Feature#21957] Introduce `Enumerable#close` to free internal resources.
by ioquatix (Samuel Williams) 19 Mar '26

19 Mar '26

Issue #21957 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #21957: Introduce `Enumerable#close` to free internal resources. https://bugs.ruby-lang.org/issues/21957 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- In some cases, `Enumerable` has substantial internal state (e.g. Fiber) related to enumeration. There is currently no way to clear up this state besides garbage collection, which means that we can accumulate considerable garbage before cleaning up, even if we know when the enumerable is no longer needed. I'd like to introduce `Enumerable#close` which invalidates the enumerable, freeing internal resources. After which, most usage would result in `Enumerable::ClosedError`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124905] [Ruby Feature#21932] `MatchData#get_int`
by nobu (Nobuyoshi Nakada) 18 Mar '26

18 Mar '26

Issue #21932 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21932: `MatchData#get_int` https://bugs.ruby-lang.org/issues/21932 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- This is suggested by @akr today, `$~.get_int(1)` is equivalent to `$1.to_i` but does not create the intermediate string object. -- https://bugs.ruby-lang.org/

7 8

[ruby-core:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 18 Mar '26

18 Mar '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125062] [Ruby Misc#21956] DevMeeting-2026-05-13
by mame (Yusuke Endoh) 18 Mar '26

18 Mar '26

Issue #21956 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21956: DevMeeting-2026-05-13 https://bugs.ruby-lang.org/issues/21956 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/05/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/05/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

1 1