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

[ruby-core:127066] [Ruby Feature#10882] Provide Levenshtein distance implementation as part of stdlib
by Mrlaura (QUANG NGUYEN) 11 Oct '26

11 Oct '26

Issue #10882 has been updated by Mrlaura (QUANG NGUYEN). Hi Yuki, Kouhei, Robert, and the Ruby maintainers, First, thank you for raising this proposal. I think the original observation remains relevant: Levenshtein distance is a relatively small algorithm with applications across many independent Ruby projects, including spelling correction, search, bioinformatics, data cleaning, and approximate string matching. I also appreciate the discussion about whether the functionality belongs in the standard library or should remain available through specialized gems. After looking at Ruby's existing implementation in DidYouMean, I would like to add a few considerations that may help clarify what a reusable public Levenshtein API should provide. The main question, in my view, is not whether Ruby can calculate Levenshtein distance. It already can. The more interesting question is whether Ruby should expose a stable, documented, reusable edit-distance API, and what guarantees such an API should make. ## 1. Ruby already has an internal Levenshtein implementation The DidYouMean library contains a Levenshtein implementation under: `lib/did_you_mean/levenshtein.rb` The implementation exposes a `distance` method internally, but the module is marked with `:nodoc:`. DidYouMean's SpellChecker also uses Jaro-Winkler similarity and Levenshtein distance as separate stages of its suggestion process. That is useful existing functionality, but I would distinguish an internal implementation detail from a public API intended for arbitrary Ruby applications. An internal implementation can reasonably optimize for its particular callers. A general-purpose API needs a more explicit contract covering: - The definition of one sequence element. - Supported edit operations. - Return-value semantics. - Unicode handling. - Performance guarantees. - Threshold-based comparisons. - Edge cases and error behavior. Reusing the existing implementation may be possible, but promoting it directly to a stable public API would deserve a review of these contracts. ## 2. Prefer an explicit namespace over a generic String#distance method The original proposal considers: ```ruby require "distance" Distance.levenshtein(str1, str2) ``` It also suggests: ```ruby "word".distance("other") ``` I would lean toward the first approach, or another explicitly named and opt-in namespace. The name `String#distance` is convenient, but it does not communicate which distance model is being used. That becomes important as soon as an application introduces: - Levenshtein distance. - Damerau-Levenshtein distance. - Hamming distance. - Weighted edit distance. - Jaro similarity. - Jaro-Winkler similarity. Some of these algorithms return edit costs, while others commonly return normalized similarity scores. Their values are not necessarily interchangeable. For example, a raw Levenshtein distance of 2 is not semantically equivalent to a Jaro-Winkler similarity of 0.82. An explicit API such as: ```ruby Distance.levenshtein(a, b) ``` makes the chosen operation immediately visible. It also avoids adding a very general method name to every String instance. I would favor a small initial API over a broad abstraction that attempts to support every possible string similarity metric. ## 3. The Unicode representation problem should be defined before implementation One important question that did not receive much attention in the original discussion is: **What exactly counts as one character in the distance calculation?** For ASCII strings, this distinction is rarely visible. For Unicode text, however, byte sequences, Unicode code points, and extended grapheme clusters are different units. Consider: ```ruby text = "é" text.bytesize # 2 text.codepoints.length # 1 text.grapheme_clusters.length # 1 ``` Now consider a canonically equivalent representation: ```ruby text = "e\u0301" text.bytesize # 3 text.codepoints.length # 2 text.grapheme_clusters.length # 1 ``` Both strings may appear identical to a user, but they have different underlying code-point sequences. A code-point-based Levenshtein implementation calculates a distance of 2 between these two representations. A grapheme-based implementation operating on the original, unnormalized clusters calculates a distance of 1. After NFC normalization, both representations become identical and their distance becomes 0. All three results can be explained by the chosen comparison model. This does not mean one implementation is necessarily incorrect. It means the sequence representation and normalization policy must be defined. Ruby already provides useful APIs such as: - `String#codepoints` - `String#each_codepoint` - `String#grapheme_clusters` - `String#each_grapheme_cluster` - `String#unicode_normalize` These could support different explicit comparison models without requiring the core edit-distance recurrence to change. ## 4. A small reference implementation illustrates the distinction Here is a simple unit-cost Levenshtein implementation that accepts arrays of arbitrary comparable elements. It is intended as a correctness reference, not as a proposal to replace Ruby's optimized internal implementation. ```ruby def levenshtein_units(a, b) a, b = b, a if b.length > a.length previous = (0..b.length).to_a a.each_with_index do |left, i| current = [i + 1] b.each_with_index do |right, j| cost = left == right ? 0 : 1 current << [ previous[j + 1] + 1, current[j] + 1, previous[j] + cost ].min end previous = current end previous[-1] end ``` This calculates standard Levenshtein distance using insertion, deletion, and substitution, each with unit cost. Its time complexity is O(mn), while auxiliary space is O(min(m,n)). For ordinary strings: ```ruby a = "kitten" b = "sitting" levenshtein_units( a.codepoints, b.codepoints ) # 3 ``` For canonically equivalent Unicode strings: ```ruby a = "é" b = "e\u0301" levenshtein_units( a.codepoints, b.codepoints ) # 2 levenshtein_units( a.grapheme_clusters, b.grapheme_clusters ) # 1 ``` After NFC normalization: ```ruby a = a.unicode_normalize(:nfc) b = b.unicode_normalize(:nfc) levenshtein_units( a.grapheme_clusters, b.grapheme_clusters ) # 0 ``` This illustrates how the same Levenshtein recurrence can operate over different sequence units. For a general-purpose Ruby API, I think the critical design decision is whether to expose these choices directly or provide a well-documented default with more specialized processing left to callers. ## 5. Mathematical Unicode characters expose another interesting case Unicode compatibility characters introduce a different class of comparison problem. Consider: `ABC` `𝐀𝐁𝐂` The second string contains mathematical bold Unicode characters. These are not simply ordinary Latin characters displayed using a different CSS font. They are different Unicode code points. A code-point-based Levenshtein calculation returns: ```ruby a = "ABC" b = "𝐀𝐁𝐂" levenshtein_units( a.codepoints, b.codepoints ) # 3 ``` After NFKC compatibility normalization: ```ruby a = a.unicode_normalize(:nfkc) b = b.unicode_normalize(:nfkc) levenshtein_units( a.codepoints, b.codepoints ) # 0 ``` The distance algorithm has not changed. Only the input representation has changed. This distinction matters in: - Search and indexing. - Duplicate detection. - Usernames and profile text. - Mathematical notation. - Document comparison. - Unicode-styled text. - Multilingual text processing. However, I would not recommend applying NFKC automatically in a general-purpose edit-distance API. Compatibility normalization deliberately removes distinctions that may be meaningful in certain applications. A better design may be to keep normalization explicit and let callers choose the appropriate transformation before comparison. For a detailed discussion of the interaction between Unicode normalization, extended grapheme clusters, and edit distance, the following technical reference may be useful: https://www.levenshtein.net/unicode-and-grapheme-safe-levenshtein ## 6. Threshold-aware distance could be a valuable optimization Another question concerns performance when the caller only wants to know whether two strings are sufficiently similar. For example: "Does the edit distance between these strings exceed 3?" A standard dynamic programming implementation calculates the complete distance even when the caller only requires a threshold decision. An API could optionally support a maximum edit distance: ```ruby Distance.levenshtein( "kitten", "sitting", max_distance: 3 ) ``` One possible contract would return the exact distance if it is at most the threshold, and `nil` otherwise. The exact return-value convention would need discussion, particularly to distinguish an exceeded threshold from an invalid input. Several safe optimizations are possible. **Length-difference filtering** For standard unit-cost Levenshtein distance: `distance(a, b) >= abs(length(a) - length(b))` If the length difference already exceeds the threshold, the calculation can terminate immediately. **Banded dynamic programming** When the maximum permitted distance is small, the implementation can avoid evaluating cells that cannot participate in a valid alignment within the threshold. **Early termination** A correctly implemented threshold-aware dynamic programming algorithm can abandon a candidate when the remaining computation cannot produce a distance within the permitted bound. These techniques can be valuable for spelling correction, approximate search, and large candidate sets. They also raise an API-design question: Should threshold-aware comparison be part of the initial public API, or should it be introduced later as a separate operation? For background on correctness, memory optimization, and bounded Levenshtein computation, this implementation-oriented reference may be useful: https://www.levenshtein.net/levenshtein-implementations ## 7. A public API should have an explicit correctness test suite If a reusable implementation is considered for the standard library, I would suggest a focused test suite covering both ordinary edit-distance behavior and Unicode representation issues. **Basic correctness** - Identical strings return 0. - Empty strings return the length of the nonempty sequence. - One insertion has cost 1. - One deletion has cost 1. - One substitution has cost 1. - Symmetry is preserved. - The triangle inequality holds for standard unit-cost Levenshtein distance. **Standard examples** - `kitten` versus `sitting`: distance 3. - `flaw` versus `lawn`: distance 2. - `Saturday` versus `Sunday`: distance 3. **Algorithm distinction** - `ab` versus `ba`: standard Levenshtein distance 2. This last example is useful because Damerau-Levenshtein permits adjacent transpositions, while ordinary Levenshtein does not. **Unicode behavior** - Precomposed versus decomposed accented characters. - Supplementary-plane Unicode characters. - Emoji sequences with zero-width joiners. - Grapheme clusters containing combining marks. - Mathematical compatibility characters. - Strings with different but compatible encodings. - Invalid byte sequences and explicitly defined encoding errors. **Performance and resource safety** - Highly unequal input lengths. - Empty input on either side. - Large strings with a small distance threshold. - Very long strings requiring a bounded-memory implementation. - Comparisons against a simple full-matrix reference implementation. For optimized implementations, differential testing against a straightforward reference algorithm would be particularly useful. ## 8. Keep the initial public API deliberately small Although there are many opportunities for extensions, I would prefer a minimal and stable first interface. For example: ```ruby require "distance" Distance.levenshtein(a, b) ``` With a clearly documented contract specifying: - Standard unit-cost Levenshtein distance. - Insertion, deletion, and substitution only. - Exact integer return value. - A defined sequence unit. - No implicit Unicode normalization. - Explicit behavior for unsupported encodings. - Predictable memory characteristics. Features such as weighted costs, different sequence units, normalization policies, edit scripts, and maximum-distance limits could be considered separately. There is also a reasonable alternative: keep string-specific comparison in a dedicated library rather than expanding Ruby's standard library. The trade-off deserves explicit discussion. A standard-library API offers consistency and discoverability. A specialized gem offers more flexibility for algorithm variants, Unicode policies, and performance experimentation. The existence of an internal implementation in DidYouMean provides a useful starting point, but it does not automatically settle that architectural question. ## Final thoughts I think this feature request remains interesting because Levenshtein distance sits at the intersection of several important areas of software engineering. It is simultaneously: - A well-defined dynamic programming algorithm. - A reusable sequence-distance metric. - A foundation for spelling correction and approximate matching. - A practical example of why Unicode representation matters. - A building block for search, indexing, and bioinformatics. The central design question is not simply where to place the implementation. It is whether Ruby can provide a public contract that clearly defines what is being compared, which operations are permitted, and what callers can rely on across Ruby versions. I would be interested in hearing whether the maintainers see value in a small, namespaced API built around standard unit-cost Levenshtein distance, with Unicode normalization and more specialized comparison models remaining explicit responsibilities of callers. For transparency, I contribute to the technical resources at Levenshtein.net referenced above. The links are included for the specific implementation and Unicode comparison details discussed here, not as proposed dependencies. Thank you again for the original proposal and for the work already done in Ruby's text-processing ecosystem. ---------------------------------------- Feature #10882: Provide Levenshtein distance implementation as part of stdlib https://bugs.ruby-lang.org/issues/10882#change-119464 * Author: yuki24 (Yuki Nishijima) * Status: Open ---------------------------------------- [Levenshtein distance algorithm](http://en.wikipedia.org/wiki/Levenshtein_distance) has been used by Rubygems, Bundler, did_you_mean and Rails and I think it's popular enough to provide it as part of Ruby's stdlib. It still seems a bit too high-level though, but definitely useful (e.g. [adding "did you mean?" to rake](https://github.com/ruby/rake/pull/29)) API-wise, I would like to propose something like the following, but I'm totally open to hear the core team's opinions as I'm not sue if this is great. ```ruby require 'distance' Distance.levenshtein(str1, str2) ``` It would also be interesting to have `#distance` method on `String`: ```ruby "word".distance("other") ``` which is implemented as: ```ruby def distance(str, algorithm = :levenshtein) # calculate the distance here. end ``` so it can allow to change the algorythm when we add more (e.g. [Jaro–Winkler distance](http://en.wikipedia.org/wiki/Jaro%E2%80%93Winkler_distance)) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126675] [Ruby Feature#22309] Allow super in a module method to work if method was called by refinement method super
by jeremyevans0 (Jeremy Evans) 10 Oct '26

10 Oct '26

Issue #22309 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #22309: Allow super in a module method to work if method was called by refinement method super https://bugs.ruby-lang.org/issues/22309 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Ruby started allowing refinements of modules in 2.4. However, there was one limitation, which is that while the refinement method could call `super` to call the module method, the module method could not call `super`, because it did not have enough information to determine the appropriate ancestor. This limitation was known at the time and was accepted when module refinements were accepted in #12534. As discussed in #22071, `super` wasn't actually prohibited in the module method, it just used the incorrect method lookup, looking for a super method in `BasicObject`. After discussion in #22071, I fixed this to use an explicit exception for this case, so an error was was raised for it. While that addressed the incorrect super method lookup issue, it was an unsatisfying conclusion. I kept thinking about ways to actually fix the issue. My initial idea was to use a separate `T_ICLASS` for the module being refined in every class ancestry chain where it could be called via refinement `super`. However, that approach would result in a large amount of complexity, as well as potentially significant additional memory. I am instead proposing an alternative approach which relies on the fact that when we call `super` in the module method, we know that the current method is a module method, and that the previous method in the call stack is a refinement method. We can walk up the call stack to find the refinement method, look at the previous method calling that to determine the class to use for the super lookup. Note that the previous method may use a different receiver/method, in which case we start with the receiver's class. There are cases where we need to do this multiple times, if there are multiple refinements or multiple modules being refined that have already called super to reach this point. I'm not sure this alternative approach works in all cases, but I have gotten it to work every case I've tried: * Module and refinement appears multiple times in the ancestor chain * `super` calls both directly in method as well as in nested blocks in method * Both refinement method and module method are bmethods * Refinement refines multiple modules and both modules are involved in the same super call chain * Multiple refinements of the same module method * Use of ZSUPER aliases in the super call chain * The `super` call in the module method is not found, and `NoMethodError` is raised correctly We want the behavior of module refinement `super` to be consistent, so in addition to fixing `super` itself, we also need to fix `defined?(super)` as well as `Method#super_method` and `UnboundMethod#super_method`. `defined?(super)` is fixed by sharing the lookup that `super` now uses. However, `Method#super_method` and `UnboundMethod#super_method` require a different approach. Thankfully, `struct METHOD` already has a member named `iclass` that is used to implement `#super_method`. So we just need to make adjustments to the setting of the `iclass` member for `#super_method` to work. Simple example: ```ruby module M def m = [:M, *super] end class C prepend M def m = :C end module R refine M do def m = [:R, *super] end end using R C.new.m # => [:R, :M, :C] ``` I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/18797 -- https://bugs.ruby-lang.org/

3 12

[ruby-core:126919] [Ruby Feature#22404] Make Data (and/or Struct, etc.) true "first-class citizens" and thank you!
by asoffa (Aaron Soffa) 10 Oct '26

10 Oct '26

Issue #22404 has been reported by asoffa (Aaron Soffa). ---------------------------------------- Feature #22404: Make Data (and/or Struct, etc.) true "first-class citizens" and thank you! https://bugs.ruby-lang.org/issues/22404 * Author: asoffa (Aaron Soffa) * Status: Open ---------------------------------------- First of all, I would like to give a **huge** shoutout to the Ruby community for staying true to Ruby's mission of increasing developer productivity and thereby happiness and thereby enrichment of people's lives, especially mine in so many ways! THANK YOU! As a scientist (who likes data), I have ultimately so far discovered **only** this (relatively minor!) nitpick about the Ruby programming language: data/value objects are not "first-class citizens" for constants in the way that general modules and classes are. The current solution is to write something like ```ruby D = Data.define(:x, :y) do self::D_CONSTANT = 1 end ``` where the `self::` is required to keep `D_CONSTANT` in the scope of `D` here. Alternatively, we can write the following: ```ruby D = Data.define(:x, :y) class D D_CONSTANT = 1 end ``` which reopens the `D` class to keep `D_CONSTANT` scoped to `D` or otherwise ```ruby class D < Data.define(:x, :y) D_CONSTANT = 1 end ``` which creates an anonymous class (which is not generally desired). My proposal is for something like the following: ```ruby class D = Data.define(:x, :y) D_CONSTANT = 1 end ``` to avoid the above complications. This enhancement request may or may not make sense depending on how frequently `Data` (and/or `Struct`, etc.) are to be considered "first-class citizens" in Ruby. My thought is that the `=` in the class definition here very nicely dovetails with the `<` for creating subclasses and also with the relatively new `=` syntax now allowed for method definitions (e.g. `def f = 1`). This enhancement would be analogous to allowing upgrading ```ruby C = Class.new do self::C_CONSTANT = 1 end ``` to ```ruby class C C_CONSTANT = 1 end ``` for `Data`, `Struct`, etc. and would address the last points mentioned in [1]. [1] https://bugs.ruby-lang.org/issues/16122 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:127023] [Ruby Bug#22421] `RubyVM::YJIT.max_compile_time_ns=` aborts the process when YJIT is not enabled
by znz (Kazuhiro NISHIYAMA) 10 Oct '26

10 Oct '26

Issue #22421 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #22421: `RubyVM::YJIT.max_compile_time_ns=` aborts the process when YJIT is not enabled https://bugs.ruby-lang.org/issues/22421 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Assignee: jit * ruby -v: ruby 4.1.0dev (2026-10-09T00:54:42Z master 21f68cfec7) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Calling `RubyVM::YJIT.max_compile_time_ns=` (added by [Feature #22236]) before YJIT is enabled aborts the process with a Rust panic. ``` $ ruby -v ruby 4.1.0dev (2026-10-09T00:54:42Z master 21f68cfec7) +PRISM [x86_64-linux] $ ruby -e 'RubyVM::YJIT.max_compile_time_ns = 10' thread '<unnamed>' (10) panicked at /usr/src/ruby/yjit/src/codegen.rs:11313:43: called `Option::unwrap()` on a `None` value note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' (10) panicked at .../library/core/src/panicking.rs:225:5: panic in a function that cannot unwind Aborted (core dumped) ``` The same happens with `ruby --yjit-disable -e 'RubyVM::YJIT.max_compile_time_ns = 10'`. It works as expected once YJIT is enabled, either with `--yjit` or after `RubyVM::YJIT.enable`: ``` $ ruby --yjit -e 'RubyVM::YJIT.max_compile_time_ns = 10; p RubyVM::YJIT.max_compile_time_ns' 10 $ ruby -e 'RubyVM::YJIT.enable; RubyVM::YJIT.max_compile_time_ns = 10; p RubyVM::YJIT.max_compile_time_ns' 10 ``` The reader side does not crash (`RubyVM::YJIT.max_compile_time_ns` and `RubyVM::YJIT.total_compile_time_ns` return 0 when YJIT is not enabled). The panic is the `unwrap()` in `CodegenGlobals::get_instance()` (yjit/src/codegen.rs), which is `None` until YJIT is initialized. Other YJIT methods that touch the globals (for example `reset_stats!` or `enable`) check `CodegenGlobals::has_instance()` or the enabled state first. Expected behavior: either store the value so that it takes effect when YJIT is enabled later (useful for the warmup-budget use case in [Feature #22236], where the budget may be set early in a boot script), or raise a Ruby exception, but not abort the process. Reproduced in the `ghcr.io/ruby/ruby:master` Docker image (x86_64-linux). -- https://bugs.ruby-lang.org/

1 1

[ruby-core:127007] [Ruby Bug#22416] Respect timezone abbreviation encodings in `Time#strftime`
by nobu (Nobuyoshi Nakada) 09 Oct '26

09 Oct '26

Issue #22416 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22416: Respect timezone abbreviation encodings in `Time#strftime` https://bugs.ruby-lang.org/issues/22416 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `Time#strftime` treats non-ASCII timezone abbreviations as if their bytes use the locale encoding. However, a timezone object's `abbr` method can return a `String` in another encoding. In that case, formatting `%Z` can produce corrupted text or a result with an unexpected encoding. Timezone objects have been supported since Ruby 2.6.0, so this issue affects Ruby 2.6.0 and later. Reproduction: ```ruby zone = Object.new def zone.local_to_utc(t) = t def zone.utc_to_local(t) = t def zone.abbr(t) = "東京標準時".encode(Encoding::Shift_JIS) time = Time.new(2020, 1, 1, 0, 0, 0, zone) result = time.strftime("☆%Z") p result p result.encoding ``` Expected: `result` contains `☆東京標準時` and is valid UTF-8. Instead, the text may be corrupted because the abbreviation's bytes are interpreted using the locale encoding. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126553] [Ruby Bug#22284] Passing an object with to_int to curry as its arity causes problems with LLP64.
by YO4 (Yoshinao Muramatsu) 09 Oct '26

09 Oct '26

Issue #22284 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #22284: Passing an object with to_int to curry as its arity causes problems with LLP64. https://bugs.ruby-lang.org/issues/22284 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: master * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The proc_curry function in proc.c is affected by differences in behavior caused by the int size in FIX2INT. As a result, depending on the arguments, curry may not function correctly on Windows. ``` method(:puts).curry(1r).call(42) => #<Proc:0x0000000005e06c58 (lambda)> (Windows) => 42 (others) ``` The same thing happens in gems/src/rbs/test/stdlib/Proc_test.rb:113. It also triggers an assertion in a debug build on windows. ``` irb(main):001> method(:puts).curry(1r).call(42) S:\git\ruby\ruby\include\ruby/internal/arithmetic/long.h:192: Assertion Failed: rbimpl_fix2long_by_shift:RB_FIXNUM_P(x) ...(snip) -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF82F2E0404] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF82C53C11F] S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_print_backtrace+0x3e) [0x00007FFF45D706CA] S:\git\ruby\ruby\vm_dump.c:1137 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_vm_bugreport+0x288) [0x00007FFF45D70958] S:\git\ruby\ruby\vm_dump.c:1482 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_assert_failure_detail+0xbb) [0x00007FFF45C05557] S:\git\ruby\ruby\error.c:1227 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_assert_failure+0x12) [0x00007FFF45C0549A] S:\git\ruby\ruby\error.c:1202 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(proc_curry+0xfa) [0x00007FFF45D48426] S:\git\ruby\ruby\proc.c:4614 ...(snip) ``` proc.c:4614 has this ``` sarity = FIX2INT(arity); ``` FIX2INT is being used, and based on what I've read in doc/extension.rdoc, I'm not entirely sure if it's correct for curry to use to_int. So just reporting this for now before submitting a PR. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126860] [Ruby Bug#22384] Regexp compile error in the 2nd+ branch of a top-level alternation leaks the parse tree (regression from #13332, Ruby 4.0)
by sethuarun (Sethupathi Arunachalam) 09 Oct '26

09 Oct '26

Issue #22384 has been reported by sethuarun (Sethupathi Arunachalam). ---------------------------------------- Bug #22384: Regexp compile error in the 2nd+ branch of a top-level alternation leaks the parse tree (regression from #13332, Ruby 4.0) https://bugs.ruby-lang.org/issues/22384 * Author: sethuarun (Sethupathi Arunachalam) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- **Affects:** ruby 4.0.6 and 4.0.7 (official docker images and a jemalloc-linked build), master (commit still present). **Not affected:** 3.4.6. **Repro (plain Ruby, no extensions):** ```ruby def rss_kb = File.read('/proc/self/status')[/VmRSS:\s+(\d+)/, 1].to_i GC.start; b = rss_kb 500_000.times { Regexp.new("a|b(c") rescue nil } # RegexpError in the 2nd branch GC.start; puts "#{rss_kb - b} KB" # 4.0.6/4.0.7: ~65500 KB (134 B per compile); 3.4.6: 0 500_000.times { Regexp.new("b(c") rescue nil } # same error, no alternation: 0 KB on both ``` Also leaks: "a|b|c(d" (3rd branch), "a|b)c(d". Does not leak: nested "(a|b(c)". **Why it matters:** `Regexp#to_s` (rb_reg_str_with_term, re.c) re-runs onig_new on the inner pattern of any regexp whose source starts with "(?flags:" and ends with ")" to decide whether the prefix can be dropped. For every regexp shaped `/(?:a|b)c(d)/` that inner pattern is "a|b)c(d", which hits this leak. Rails calls Regexp#to_s on every Regexp in config.filter_parameters for every request (ActiveSupport::ParameterFilter compile_filters!, one ParameterFilter per request), and Rails precompiles filter_parameters into exactly that shape, so a Rails 7.1+/8.x app with a Regexp filter leaks ~128 B per request per process on Ruby 4.0. Observed on production: +3.4 MB/h per puma worker, 145 MB per worker after 40 h (jemalloc profile stacks: rb_reg_str_with_term → onig_new → onig_parse_make_tree → parse_subexp → parse_branch → parse_exp). **Cause:** commit 35000ac2ed "Prevent double free for too big repetition quantifiers (#13332)", regparse.c parse_subexp(). Before it, the alternation list was assigned to `*top` immediately and the loop's error paths called `onig_node_free(node)`. After it, the list lives in the local `topnode` and both error paths call `onig_node_free(topnode)` only. That is right for the `fetch_token` failure (`node` was already linked into topnode by the previous iteration), but wrong for the `parse_branch` failure: parse_branch returns the partially built branch in `*top` (see its `*top = node_new_list(node, NULL)` before the loop) and that node is not yet linked into topnode, so it is never freed. **Fix:** ```diff r = parse_branch(&node, tok, term, src, end, env); if (r < 0) { + onig_node_free(node); onig_node_free(topnode); return r; } ``` (parse_branch's own error path frees only the element that failed and leaves the list in *top, as it did before #13332; the top-level `if (r < 0) { onig_node_free(node); return r; }` a few lines above already does the same for the first branch.) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126828] [Ruby Bug#22342] IO#gets can ignore the limit argument in some edge cases
by rhenium (Kazuki Yamaguchi) 09 Oct '26

09 Oct '26

Issue #22342 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22342: IO#gets can ignore the limit argument in some edge cases https://bugs.ruby-lang.org/issues/22342 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `io.gets(rs, limit)` ignores the `limit` value and reads until `rs` is found or EOF, if the `limit`-th byte of the stream matches `rs`'s last byte and: 1. The potential start of the record separator, the `limit-rs.bytesize`-th byte of the stream is not at a character boundary ```ruby str = "\x83\\xxx".force_encoding("Windows-31J") # "ソxxx".encode("Windows-31J") IO.pipe("Windows-31J"){|r,w|w.write(str); w.close_write; p r.gets("\\", 2); p r.read} # Expected: "\x{835C}" "xxx" # Actual: "\x{835C}xxx" "" ``` 2. Or, `limit < rs.bytesize` ```ruby IO.pipe{|r,w|w.write("a:bc"); w.close_write; p r.gets(":::", 2); p r.read} # Expected: "a:" "bc" # Actual: "a:bc" "" ``` This behavior appears to date back to Ruby 1.9.x. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126848] [Ruby Bug#22380] Ruby::Box: a GC while copying a class into a box crashes
by hsbt (Hiroshi SHIBATA) 09 Oct '26

09 Oct '26

Issue #22380 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22380: Ruby::Box: a GC while copying a class into a box crashes https://bugs.ruby-lang.org/issues/22380 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 4.0.7 (2026-09-22 revision 9aea6bb2f1) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- This is a backport request for the following crash: ``` $ RUBY_BOX=1 ruby --disable-gems -W:no-experimental -e 'GC.stress = true; module Enumerable; def m; end; end' -e:1: [BUG] try to mark T_NONE object (obj: 0x00000001042efe28 T_NONE/, parent: 0x000000010416dc08 T_MODULE/Module Enumerable) ``` Fixed on master by 44fff96b0bc and 18b6bfdb67e (https://github.com/ruby/ruby/pull/18842) Ruby 4.0.7 still crashes. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126824] [Ruby Bug#22339] Ruby::Box: crash / hang at VM shutdown with RUBY_FREE_AT_EXIT=1
by Eregon (Benoit Daloze) 09 Oct '26

09 Oct '26

Issue #22339 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22339: Ruby::Box: crash / hang at VM shutdown with RUBY_FREE_AT_EXIT=1 https://bugs.ruby-lang.org/issues/22339 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-21T14:42:24Z master 41e04ff507) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- ## Summary With `RUBY_BOX=1` and `RUBY_FREE_AT_EXIT=1`, Ruby crashes or hangs while freeing boxes at VM shutdown. No user box needs to be created: the built-in boxes are enough. `box_entry_free()` walks `box->classext_cow_classes` at shutdown, but the objects in that table have already been freed by the shutdown sweep, so `free_classext_for_box()` sees a type that is no longer `T_CLASS`/`T_MODULE`/`T_ICLASS` and calls `rb_bug()`. Under ASAN the same teardown is caught one step earlier, as an iclass classext freed twice. ## Reproduction ```console $ RUBY_BOX=1 RUBY_FREE_AT_EXIT=1 ruby -e '' ``` Either environment variable alone is fine; only the combination fails. ## Observed behaviour `ruby 4.1.0dev (2026-09-21T14:42:24Z master 41e04ff507) +PRISM [arm64-darwin25]` hangs, spinning at 99% CPU. `sample(1)` of the main thread: ``` rb_ec_cleanup rb_objspace_call_finalizer rb_gc_obj_free box_entry_free (box.c, st_foreach over classext_cow_classes) st_general_foreach free_classext_for_box rb_bug ("Invalid type of object in classext_cow_classes: %s") rb_bug_without_die_internal rb_source_location_cstr _sigtramp <- SIGSEGV while printing the bug report sigsegv rb_bug_for_fatal_signal rb_source_location_cstr rb_iseq_path <- loops here forever ``` `ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [aarch64-linux]` (docker `ruby:4.0.7-slim-trixie`) dies with SIGSEGV (exit 139, core dumped) instead of hanging. The offending branch is in `free_classext_for_box()`: ```c if (RB_TYPE_P(obj, T_CLASS) || RB_TYPE_P(obj, T_MODULE)) { ... } else if (RB_TYPE_P(obj, T_ICLASS)) { ... } else { rb_bug("Invalid type of object in classext_cow_classes: %s", rb_type_str(BUILTIN_TYPE(obj))); } ``` ## ASAN evidence A Linux ASAN build of master reports a use-after-free in the same shutdown teardown, where the same `id_table` is freed twice through the identical call path: ``` ERROR: AddressSanitizer: heap-use-after-free, READ of size 8 #0 rb_id_table_free id_table.c:112:16 #1 rb_iclass_classext_free class.c:128:9 #2 rb_class_classext_foreach class.c:460:5 #3 rb_gc_obj_free gc.c:1402:9 #4 rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3087:25 #5 rb_objspace_call_finalizer gc.c:1739:5 #6 rb_ec_finalize eval.c:177:5 #7 rb_ec_cleanup eval.c:268:5 freed by thread T0 here: #0 free #1 rb_gc_impl_free gc/default/default.c:8285:9 #2 rb_iclass_classext_free class.c:128:9 #3 rb_class_classext_foreach class.c:460:5 #4 rb_gc_obj_free gc.c:1402:9 #5 rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3087:25 #6 rb_objspace_call_finalizer gc.c:1739:5 ``` That build additionally had a user box created before exit; the `rb_bug` reproduction above does not need one. ## Affected versions Same one-liner on each build: | build | result | | --- | --- | | master `41e04ff507`, arm64-darwin25 | hang (99% CPU) | | 4.0.7, 4.0.6, 4.0.3 (ruby-build), arm64-darwin25 | hang (99% CPU) | | 4.0.7 linux (`ruby:4.0.7-slim-trixie`, `ruby:4.0.7-slim-bookworm`) | SIGSEGV | | 4.0.6 linux (`ruby:4.0.6-slim-trixie`) | SIGSEGV | | 4.0.5, 4.0.3, 4.0.2, 4.0.1 linux (`ruby:4.0.x-slim`, `-slim-trixie`) | exits 0 | The base image makes no difference (bookworm and trixie behave the same), so this is the Ruby build rather than the distribution. Since the underlying defect is a use-after-free, the rows that exit 0 are presumably latent rather than unaffected: whether the freed object still reads back as a class depends on allocator reuse. ## Possibly a separate issue Once `rb_bug()` is reached at this point in shutdown, the bug reporter itself crashes in `rb_source_location_cstr()`, and the fatal signal handler re-enters the same function, so the process never terminates. A `rb_bug()` this late should still be able to abort. -- https://bugs.ruby-lang.org/

3 2