- ruby-core - ml.ruby-lang.org

[ruby-core:125179] [Ruby Feature#18254] Add an `offset` parameter to String#unpack and String#unpack1
by nobu (Nobuyoshi Nakada) 01 Apr '26

01 Apr '26

Issue #18254 has been updated by nobu (Nobuyoshi Nakada). I wasn't aware that negative offset is not allowed. Shouldn't `unpack`/`unpack1` also it as well as the other methods, `String#slice`, `String#[]` and so on? ---------------------------------------- Feature #18254: Add an `offset` parameter to String#unpack and String#unpack1 https://bugs.ruby-lang.org/issues/18254#change-116911 * Author: byroot (Jean Boussier) * Status: Closed ---------------------------------------- When working with binary protocols it's common to have to first unpack some kind of header or type prefix, and then based on that unpack another part of the string. For instance here's [a code snippet from Dalli, the most common Memcached client](https://github.com/petergoldstein/dalli/blob/76b79d78cda13562da17bc…: ```ruby while buf.bytesize - pos >= 24 header = buf.slice(pos, 24) (key_length, _, body_length, cas) = header.unpack(KV_HEADER) if key_length == 0 # all done! @multi_buffer = nil @position = nil @inprogress = false break elsif buf.bytesize - pos >= 24 + body_length flags = buf.slice(pos + 24, 4).unpack1("N") key = buf.slice(pos + 24 + 4, key_length) value = buf.slice(pos + 24 + 4 + key_length, body_length - key_length - 4) if body_length - key_length - 4 > 0 pos = pos + 24 + body_length begin values[key] = [deserialize(value, flags), cas] rescue DalliError end else # not enough data yet, wait for more break end end @position = pos ``` ### Proposal If `unpack` and `unpack1` had an `offset:` parameter, it would allow this kind of code to extract the fields it needs without allocating and copying as much strings, e.g.: ```ruby flags = buf.slice(pos + 24, 4).unpack1("N") ``` could be: ```ruby buf.unpack1("N", offset: pos + 24) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125176] [Ruby Bug#21978] Fix class variable cache isn't invalidated via modules
by jhawthorn (John Hawthorn) 01 Apr '26

01 Apr '26

Issue #21978 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21978: Fix class variable cache isn't invalidated via modules https://bugs.ruby-lang.org/issues/21978 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby module M; @@x = 1; end class A; end class B < A include M def self.x; @@x; end end B.x # warm cache A.class_variable_set(:@@x, 2) B.x ``` The last call to `B.x` should fail with `Should raise: class variable @@x of M is overtaken by A (RuntimeError)`, but has been returning 1 since since ruby-3.2.0-preview3. It should be solvable by by bumping the global state counter more aggressively: https://github.com/ruby/ruby/pull/16551 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125174] [Ruby Bug#21977] Ruby::Box crash with `RUBY_BOX=1` via `Binding` refinement, `UnboundMethod#bind_call`, and `Symbol#to_proc`
by singetu0096 (Rintaro Kawasugi) 01 Apr '26

01 Apr '26

Issue #21977 has been reported by singetu0096 (Rintaro Kawasugi). ---------------------------------------- Bug #21977: Ruby::Box crash with `RUBY_BOX=1` via `Binding` refinement, `UnboundMethod#bind_call`, and `Symbol#to_proc` https://bugs.ruby-lang.org/issues/21977 * Author: singetu0096 (Rintaro Kawasugi) * Status: Open * ruby -v: ruby 4.1.0dev (2026-03-24T21:47:14Z master 30dcc2a082) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I found a reproducible interpreter crash when Ruby is run with `RUBY_BOX=1`. A refinement on `Binding`, combined with `UnboundMethod#bind_call` and `Symbol#to_proc`, causes Ruby to abort with: ```text [BUG] BUG: Local ep without cme/box, flags: 66660087 ``` I reproduced this on: ```text ruby 4.1.0dev (2026-03-24T21:47:14Z master 30dcc2a082) +PRISM [x86_64-linux] ``` Follow-up validation confirmed an important discriminator: replacing `map(&:to_s)` with an explicit block such as `map { _1.to_s }` avoids the crash. The currently available evidence therefore points to a box/frame bookkeeping bug in the `Symbol#to_proc` path that reaches an explicit internal `rb_bug(...)` assertion, not to confirmed memory corruption. ## PoC ```ruby using Module.new { refine ::Binding do def eval_methods ::Kernel.instance_method(:methods).bind_call(receiver) end end } p binding.eval_methods.map(&:to_s) ``` Run: ```bash RUBY_BOX=1 ./miniruby -e ' using Module.new { refine ::Binding do def eval_methods ::Kernel.instance_method(:methods).bind_call(receiver) end end } p binding.eval_methods.map(&:to_s) ' ``` Observed result: ```text [BUG] BUG: Local ep without cme/box, flags: 66660087 ruby 4.1.0dev (2026-03-24T21:47:14Z master 30dcc2a082) +PRISM [x86_64-linux] Crashed while printing bug report ``` Important discriminator: ```ruby p binding.eval_methods.map { _1.to_s } ``` Replacing `map(&:to_s)` with an explicit block avoids the crash, which strongly suggests that the failure depends specifically on the `Symbol#to_proc` path rather than `map` in general. ## Impact The currently confirmed impact is denial of service in processes using Ruby::Box with `RUBY_BOX=1`. Confirmed claim: - reliable interpreter abort - trigger requires `RUBY_BOX=1` - trigger depends specifically on the `Symbol#to_proc` path in this setup Current non-claims: - no confirmed memory corruption - no confirmed sandbox escape - no confirmed privilege escalation - no confirmed arbitrary code execution This report should remain separate from the Ruby::Box double-free issue, because the trigger path, failure mode, and currently demonstrated impact are different. -- https://bugs.ruby-lang.org/

1 0

[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) 29 Mar '26

29 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

[ruby-core:124635] [Ruby Feature#21853] Make Embedded TypedData a public API
by byroot (Jean Boussier) 26 Mar '26

26 Mar '26

Issue #21853 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21853: Make Embedded TypedData a public API https://bugs.ruby-lang.org/issues/21853 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- As part of Ruby 3.3, we added a private `RUBY_TYPED_EMBEDDABLE` flag to the `TypedData` API to allow `TypedData` to use variable width allocation. Technically, we inadvertently exposed that flag in public headers so third party extensions can make use of it, but it's not considered public API as it's not documented, so it would be a poor decision. This API has both memory and speed benefits as it allow to avoid some `malloc/free` churn, reduce pointer chasing, etc. For instance, when we converted `Time` to be embedded, it improved allocation performance by 30% and also reduced memory usage by 20%: https://github.com/ruby/ruby/commit/aa6642de630cfc10063154d84e45a7bff30e9103 I believe numerous third party native extensions could benefit from it (I would certainly make use of it in `ruby/json`), now that we used it internally for several years, I'd like to work on making it a public API for Ruby 4.1 -- https://bugs.ruby-lang.org/

3 9

[ruby-core:125072] [Ruby Bug#21958] Snapshot CI is breaking now
by hsbt (Hiroshi SHIBATA) 26 Mar '26

26 Mar '26

Issue #21958 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21958: Snapshot CI is breaking now https://bugs.ruby-lang.org/issues/21958 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The current snapshot CI used for releases is broken since 14th March. https://github.com/ruby/actions/actions/runs/23065551523/job/67003439358 ``` compiling dump_ast making array.rbinc make[1]: Entering directory '/home/runner/work/actions/actions/snapshot-master' fatal: not a git repository (or any of the parent directories): .git make[1]: 'dump_ast' is up to date. make[1]: Leaving directory '/home/runner/work/actions/actions/snapshot-master' executable host ruby is required. use --with-baseruby option. Note that BASERUBY must be Ruby 3.1.0 or later. make: *** [uncommon.mk:1299: array.rbinc] Error 1 make: *** Waiting for unfinished jobs.... ``` and that Windows build is also failure with another issue: https://github.com/ruby/actions/actions/runs/23261354707/job/67631251910 ``` compiling eventids1.c eventids1.c compiling ../../../snapshot-master/ext/ripper/eventids2.c eventids2.c NMAKE : fatal error U1073: don't know how to make '../../probes.h' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\nmake.EXE"' : return code '0x2' Stop. ``` I also here the current build system is broken with out-of-source and cross-compile. -- https://bugs.ruby-lang.org/

2 2