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

[ruby-core:123836] [Ruby Feature#21695] Optimizing Ruby performance with Ruby itself instead of Rust
by fredlinhares (Frederico Linhares) 10 Apr '26

10 Apr '26

Issue #21695 has been reported by fredlinhares (Frederico Linhares). ---------------------------------------- Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust https://bugs.ruby-lang.org/issues/21695 * Author: fredlinhares (Frederico Linhares) * Status: Open ---------------------------------------- I am using ERB on top of C for a game I am making now. We can use the tool to improve the productivity, memory safety, and runtime speed for Ruby. It can also replace a Rust JIT compiler for better results. The only problem is that it requires some level of manual memory management, while Rust does it all for you. If I demonstrate that it is better than Rust in practice, would you be willing to incorporate it into the Ruby language? I want to know because making it more generic will require more effort from me; if you are not interested, I won’t make the tool public. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:124270] [Ruby Bug#21787] `IO::Buffer` buffer overf
by nobu (Nobuyoshi Nakada) 03 Apr '26

03 Apr '26

Issue #21787 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21787: `IO::Buffer` buffer overf https://bugs.ruby-lang.org/issues/21787 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125028] [Ruby Bug#21954] NoMethodError instead of Gem::LoadError on gem activation problem in Ruby 4.0.2
by jeremyevans0 (Jeremy Evans) 03 Apr '26

03 Apr '26

Issue #21954 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21954: NoMethodError instead of Gem::LoadError on gem activation problem in Ruby 4.0.2 https://bugs.ruby-lang.org/issues/21954 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux] * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- I'm seeing a regression in Ruby 4.0.2 when there is a gem activation problem. Install two versions of a gem, where one version has a file the other doesn't. One example here is rack: ``` $ gem install rack --version '< 3' $ gem install rack ``` Force activation of the version that doesn't have the file, and then require the file and rescue `LoadError`: ```ruby gem 'rack', '< 3' begin require 'rack/headers' rescue LoadError end ``` In previous versions of Ruby, the `Gem::LoadError` would be correctly rescued, and you would get no output. In Ruby 4.0.2, you get a `NoMethodError` raised: ``` /usr/local/lib/ruby/4.0/rubygems.rb:196:in 'Gem.try_activate': undefined method 'name' for nil (NoMethodError) spec ||= Gem::Specification.find_by_name(spec.name) ^^^^^ from /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require' from /home/jeremy/gem-activate-problem.rb:4:in '<main>' /usr/local/lib/ruby/4.0/rubygems/specification.rb:2170:in 'Gem::Specification#check_version_conflict': can't activate rack-3.2.4, already activated rack-2.2.21 (Gem::LoadError) from /usr/local/lib/ruby/4.0/rubygems/specification.rb:1379:in 'Gem::Specification#activate' from /usr/local/lib/ruby/4.0/rubygems.rb:193:in 'Gem.try_activate' from /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require' from /home/jeremy/gem-activate-problem.rb:4:in '<main>' /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require': cannot load such file -- rack/headers (LoadError) from /home/jeremy/gem-activate-problem.rb:4:in '<main>' ``` Same behavior on both OpenBSD and Linux. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125154] [Ruby Bug#21971] Backport commit 5de4cc560864 / PR #15848
by mackuba (Kuba Suder) 03 Apr '26

03 Apr '26

Issue #21971 has been reported by mackuba (Kuba Suder). ---------------------------------------- Bug #21971: Backport commit 5de4cc560864 / PR #15848 https://bugs.ruby-lang.org/issues/21971 * Author: mackuba (Kuba Suder) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Follow-up to ticket: https://bugs.ruby-lang.org/issues/21824 There was a group of old commits merged before 4.0 which were meant to improve regexp performance in some cases. Unfortunately, they also greatly degraded regexp performance in some other cases. This was released in version 4.0.0, where I noticed it when testing the performance of the final version in my app, and reported it as 21824. Chris Hasiński has fixed this on the master branch in commit 5de4cc56086493689701e86aa0ccf6a4a4a87d75, however this wasn't released as a bugfix with Ruby 4.0.1 & 4.0.2. It would be great if this could be backported to the ruby_4_0 branch and included in the 4.0.3 bugfix release. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125161] [Ruby Bug#21974] Cannot inspect RubyVM::AST for CDECL
by kddnewton (Kevin Newton) 02 Apr '26

02 Apr '26

Issue #21974 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21974: Cannot inspect RubyVM::AST for CDECL https://bugs.ruby-lang.org/issues/21974 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ./ruby -e 'pp RubyVM::AbstractSyntaxTree.parse("::Foo = 1")' ``` and ``` ./ruby -e 'p RubyVM::AbstractSyntaxTree.parse("::Foo = 1").children[2].children' ``` both crash -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125148] [Ruby Bug#21969] fork() + Socket.getaddrinfo() triggers SIGSEGV/SIGABRT via libsystem_trace.dylib on macOS 26 (darwin25) x86_64 and ARM64
by saurabhpandit (Saurabh Pandit) 30 Mar '26

30 Mar '26

Issue #21969 has been reported by saurabhpandit (Saurabh Pandit). ---------------------------------------- Bug #21969: fork() + Socket.getaddrinfo() triggers SIGSEGV/SIGABRT via libsystem_trace.dylib on macOS 26 (darwin25) x86_64 and ARM64 https://bugs.ruby-lang.org/issues/21969 * Author: saurabhpandit (Saurabh Pandit) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- On macOS 26 (darwin25), forked child processes crash with SIGSEGV (x86_64) or SIGABRT (ARM64) when calling `Socket.getaddrinfo` after the parent process has established `libsystem_trace.dylib` os_log shared-memory state through prior DNS activity. This is distinct from [#21790](https://bugs.ruby-lang.org/issues/21790) (NAT64 hang/crash in `_gai_nat64_second_pass`). The crash site here is `_os_log_preferences_refresh` and `os_log_type_enabled` inside `libsystem_trace.dylib` — the OS logging subsystem, not the DNS resolver. The stale shared-memory pointer for os_log preferences is inherited across `fork()` and dereferenced in the child, causing the fault. ### Ruby -v x86_64 ~ root# /opt/puppetlabs/puppet/bin/ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-darwin25] arm64 ~ root# /opt/puppetlabs/puppet/bin/ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] ### Crash stack (x86_64, Ruby 4.0.1 embedded — same frames observed on 3.x) ``` [BUG] Segmentation fault at 0x0000000101fd0863 ruby 4.0.1 (2025-02-26 revision ???) [x86_64-darwin25] -- C level backtrace information ------------------------------------------- _os_log_preferences_refresh + 0x2f (libsystem_trace.dylib) _os_log_preferences_check_extended (libsystem_trace.dylib) _os_log_type_enabled (libsystem_trace.dylib) ... (DNS resolution internals) Socket.getaddrinfo (ext/socket) ``` Apple's crash reporter (`asi`) confirms: "crashed on child side of fork pre-exec". ### Signal asymmetry between architectures | Architecture | Signal | Reason | |-----------|---------|---------| | x86_64 | SIGSEGV (11) | Ruby's `sigsegv` handler re-delivers the signal; child exits 11 | | ARM64 | SIGABRT (6) | Ruby's `sigabrt` handler calls `abort();` child exits 6 | Both architectures crash identically — the signal number differs only due to Ruby's signal handler behaviour. Monitoring that watches only for `termsig == 11` **will miss all ARM64 crashes** . ### Reproducer ```ruby #!/usr/bin/env ruby # frozen_string_literal: true # # Minimal Ruby-only fork reproducer for macOS 26 segfault. # Only configurable option: TRIALS=<n> # # Run: ruby reproducer.rb # Crash expected within ~10–20 trials on a primed x86_64 system. # ARM64: may crash on trial 1; check for termsig 6 (SIGABRT) not just 11. require 'socket' TRIALS = Integer(ENV.fetch('TRIALS', '50')) HOST = 'api.segment.io' PORT = 443 PRIME_THREADS = 8 SIGSEGV_NUM = 11 SIGABRT_NUM = 6 # Keep parent DNS activity running while children fork to increase race # likelihood — this primes the os_log shared-memory state in libsystem_trace. def start_prime_threads(host, port, thread_count) stop = false threads = Array.new(thread_count) do Thread.new do until stop begin Socket.getaddrinfo(host, port, nil, :STREAM) rescue nil end end end end [threads, proc { stop = true }] end puts '=== Minimal Ruby fork reproducer ===' puts "Ruby #{RUBY_VERSION} (#{RUBY_PLATFORM})" puts "Host=#{HOST} Port=#{PORT} Trials=#{TRIALS}" puts prime_threads, stop_primers = start_prime_threads(HOST, PORT, PRIME_THREADS) sleep 0.2 puts 'Priming active' puts crash_count = 0 begin TRIALS.times do |trial| pid = fork do Socket.getaddrinfo(HOST, PORT, nil, :STREAM) exit 0 rescue exit 0 end _, status = Process.waitpid2(pid) if status.signaled? && [SIGSEGV_NUM, SIGABRT_NUM].include?(status.termsig) crash_count += 1 puts "[Trial #{trial + 1}] CRASH signal=#{status.termsig}" else print '.' end end ensure stop_primers.call prime_threads.each(&:join) end puts puts '=== Summary ===' puts "CRASH: #{crash_count} / #{TRIALS}" exit(crash_count.positive? ? 1 : 0) ``` ### Observed output (x86_64-darwin25) ``` === Minimal Ruby fork reproducer === Ruby 3.4.1 (x86_64-darwin25) Host=api.segment.io Port=443 Trials=50 Priming active ......[Trial 7] CRASH signal=11 ......[Trial 14] CRASH signal=11 ... === Summary === CRASH: 8 / 50 ``` On ARM64, signal=6 (SIGABRT) is reported instead of 11. ### Conditions required 1. Parent process runs continuous `Socket.getaddrinfo` threads before forking (primes `libsystem_trace.dylib` os_log shared-memory) 2. Child calls `Socket.getaddrinfo` — this triggers `os_log_type_enabled` → `_os_log_preferences_refresh` → stale pointer dereference 3. macOS 26 (darwin25) only — not reproducible on macOS 14/15 ---Files-------------------------------- ruby_fork_resolv_getaddrinfo_prime1_x86_64.log (197 KB) ruby_fork_resolv_getaddrinfo_prime1_ARM64.log (202 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125136] [Ruby Bug#21965] cross compile with out-of-source build is broken
by hsbt (Hiroshi SHIBATA) 29 Mar '26

29 Mar '26

Issue #21965 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21965: cross compile with out-of-source build is broken https://bugs.ruby-lang.org/issues/21965 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: kddnewton (Kevin Newton) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- cross compile with out-of-source build is broken since 14th. I created simple cross-compile workflow with out-of-source build at https://github.com/ruby/ruby/pull/16545 because our CI suite is not covered that case. `ruby_4_0` branch is working fine: https://github.com/ruby/ruby/actions/runs/23571659532/job/68635350261 `master` branch is broken: https://github.com/ruby/ruby/actions/runs/23574018376/job/68642526668 ``` ... making ../src/warning.rbinc making ../src/gc.rbinc ./dump_ast: 1: ELF�@[@��5@8: not found ./dump_ast: 1: %@@@��888,�: not found ./dump_ast: 2: ,�: not found ./dump_ast: 3: ��: not found ... ``` @nobu try to fix that at https://github.com/ruby/ruby/pull/16456 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124634] [Ruby Feature#21852] New improved allocator function interface
by byroot (Jean Boussier) 27 Mar '26

27 Mar '26

Issue #21852 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21852: New improved allocator function interface https://bugs.ruby-lang.org/issues/21852 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- When implementing native types with the `TypedData` API, You have to define an allocator function. That function receive the class to allocate and is supposed to return a new instance. ```c /** * This is the type of functions that ruby calls when trying to allocate an * object. It is sometimes necessary to allocate extra memory regions for an * object. When you define a class that uses ::RTypedData, it is typically the * case. On such situations define a function of this type and pass it to * rb_define_alloc_func(). * * @param[in] klass The class that this function is registered. * @return A newly allocated instance of `klass`. */ typedef VALUE (*rb_alloc_func_t)(VALUE klass); ``` ### Current API shortcomings There are a few limitations with the current API. #### Hard to disallow `.allocate` without breaking `#dup` and `#clone`. First, it is frequent for extensions to want to disable `Class#allocate` for their native types via `rb_undef_alloc_func`, as very often allowing uninitialized object would lead to bugs. The problem with `rb_undef_alloc_func` is that the alloc func is also used internally by `dup` and `clone`, so most types that undefine the allocator also prevent object copy without necessarily realizing it. If you want to both disable `Class#allocate` yet still allow copying, you need to entirely implement the `#dup` and `#clone` methods, which is non-trivial and very few types do. One notable exception is `Binding`, which has to implement these two methods: https://github.com/ruby/ruby/blob/bea48adbcacc29cce9536977e15ceba0d65c8a02/… This works for Ruby code, however it doesn't work with C-level `rb_obj_dup(VALUE)`, as used by the Ractor logic to copy objects across ractors. In the case of `Binding` we probably wouldn't allow it anyway, but for other types it may be a problem. #### Can't support objects of variable width When duping or cloning an object of variable width, you need access to the original object to be able to allocate the right slot size. An example of that is `Thread::Backtrace` objects, as evidenced by [Bug #21818]. To support sending exception objects across ractors, we'd need to make `rb_obj_dup()` work for `Thread::Backtrace`, but to correctly duplicate a backtrace, the allocator needs to know the size. ### Proposed new API I'd like to propose a new API for defining allocators: ```ruby typedef VALUE (*rb_copy_alloc_func_t)(VALUE klass, VALUE other); ``` In addition to the class to allocate, the function also receives the instance to copy. When called by `Class#allocate`, the `other` argument is set to `Qundef`. Example usage: ```c static VALUE backtrace_alloc(VALUE klass, VALUE other) { rb_backtrace_t *bt; if (UNDEF_P(other)) { // Regular alloc return TypedData_Make_Struct(klass, rb_backtrace_t, &backtrace_data_type, bt); } else { // Copy rb_backtrace_t *other_bt; TypedData_Get_Struct(other, rb_backtrace_t, &backtrace_data_type, other_bt); VALUE self = backtrace_alloc_capa(other_bt->backtrace_size, &bt); bt->backtrace_size = other_bt->backtrace_size; MEMCPY(bt->backtrace, other_bt->backtrace, rb_backtrace_location_t, other_bt->backtrace_size); return self; } } ``` ### Backward compatibility Older-style allocator can keep being supported as long as we wish. The one backward potential compatibility concern is third party code that calls `rb_alloc_func_t rb_get_alloc_func(VALUE klass);`. As its documentation suggest, there's not much valid use case for it, but regardless we can keep supporting it by returning a "jump function". See `copy_allocator_adapter`: https://github.com/ruby/ruby/pull/15795/changes#diff-884a5a8a369ef1b4c7597e… ### Opportunity for more changes? I was discussing this new interface with @ko1 and it appears that the current allocator interface may also be a limitation for Ractors and Ractor local GC. i.e. it might be useful to let the allocator function know that we're copying from one Ractor to another. But I know to little about Ractor local GC to make a proposition here, so I will let @ko1 make suggestions. ### Implementation I implemented this idea in https://github.com/ruby/ruby/pull/15795, to solve [Bug #21818]. It could remain a purely private API, but I think it would make sense to expose it. -- https://bugs.ruby-lang.org/

3 14

[ruby-core:125144] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 27 Mar '26

27 Mar '26

Issue #6012 has been updated by Eregon (Benoit Daloze). Status changed from Closed to Rejected Revert PR: https://github.com/ruby/ruby/pull/16582 I'll mark this issue as rejected to reflect the revert. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116873 * Author: rogerdpack (Roger Pack) * Status: Rejected * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125140] [Ruby Feature#21966] Remove rb_obj_class runtime check on rb_define_alloc_func returned objects
by jhawthorn (John Hawthorn) 26 Mar '26

26 Mar '26

Issue #21966 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #21966: Remove rb_obj_class runtime check on rb_define_alloc_func returned objects https://bugs.ruby-lang.org/issues/21966 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- I want to remove the following runtime check in `class_call_alloc_func`, replacing it with a `RUBY_ASSERT` (so we would still have the check, but only on a debug build). ``` if (rb_obj_class(obj) != rb_class_real(klass)) { rb_raise(rb_eTypeError, "wrong instance allocation"); } ``` This checks that the value returned from the function registered with `rb_define_alloc_func` is of the correct class. When this was first introduced in 1fe40b7cc5 (by Matz on 2001-10-03), allocation was done via user-defined `Object#allocate`, so it made sense to have a runtime check in release builds. Now that it's defined via `rb_define_alloc_func` in the C extension API, I don't think it's necessary. The check is surprisingly expensive. Removing it makes `Object.new` [about 10% faster](https://gist.github.com/jhawthorn/318ca96f471574080e4f08b6dce759f2). It allows the C compiler to optimize the call to the function pointer as a tail-call. Removing this also allows ZJIT/YJIT to call the function directly (ZJIT already does this by having a list of known safe allocation functions). The diff in the assembly from skipping this is substantial https://gist.github.com/jhawthorn/20834b654bec4ba0bafee729592d5156 (though much of that is `rb_class_real` which I also have plans to improve). There's no way for users to ever have seen this check, other than by writing a misbehaving C extension, which returns objects with the wrong class. https://github.com/ruby/ruby/pull/16571 I don't think this should be controversial, but I'm filing a feature to make sure it has visibility. If anyone has concerns I'll revert the change and discuss here. -- https://bugs.ruby-lang.org/

1 0