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

[ruby-core:126353] [Ruby Bug#22237] GC.auto_compact corrupts a String or segfaults from String#tr with dup or gsub
by curi (Elliot Temple) 18 Aug '26

18 Aug '26

Issue #22237 has been reported by curi (Elliot Temple). ---------------------------------------- Bug #22237: GC.auto_compact corrupts a String or segfaults from String#tr with dup or gsub https://bugs.ruby-lang.org/issues/22237 * Author: curi (Elliot Temple) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `GC.auto_compact = true` can cause memory corruption or segfaults with string methods. Ruby 4.0.6, arm64 macOS, YJIT enabled, 100 runs: 35 clean, 27 corruption, 38 segfault. I also saw the issue with Ruby 4.0.4, x86-64 Debian, or YJIT disabled. ``` ruby # ruby --disable-gems autocompact-test.rb puts RUBY_DESCRIPTION input = "aaa" iterations = Integer(ENV.fetch("ITERATIONS", 10_000_000)) $stdout.sync = true GC.auto_compact = true Object.new # increases chance of memory corruption or segfault iterations.times do |i| s = input.tr("\u0080", "\u20AC").dup # gsub(/x/, "") instead of dup works too # the tr, gsub and dup should all return the original input bytes unless s == input warn "Corrupt output at iteration #{i}: #{s.bytes.inspect}" warn GC.stat.slice(:major_gc_count, :compact_count, :total_moved_objects).inspect exit 2 end end ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116370] [Ruby master Bug#20203] `TestEnumerable` test failures with GCC 14
by vo.x (Vit Ondruch) 17 Aug '26

17 Aug '26

Issue #20203 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20203: `TestEnumerable` test failures with GCC 14 https://bugs.ruby-lang.org/issues/20203 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- There is ongoing mass rebuild in Fedora and that is first time GCC 14 is used and we observe test failures in `TestEnumerable`. Here are a few examples: ~~~ [ 3000/26419] TestEnumerable#test_transient_heap_sort_bymalloc_consolidate(): unaligned fastbin chunk detected ~~~ ~~~ [ 2455/26535] TestEnumerable#test_transient_heap_sort_bycorrupted size vs. prev_size in fastbins ~~~ ~~~ [ 9716/26532] TestEnumerable#test_any_with_unused_blockdouble free or corruption (fasttop) ~~~ The full logs are accessible [here](https://koji.fedoraproject.org/koji/taskinfo?taskID=112176941). Please drill through `Descendants` and `build.log` -- https://bugs.ruby-lang.org/

6 13

[ruby-core:126427] [Ruby Bug#22248] `Errno::NOERROR` from `connect(2)` once a non-main Ractor has more than one Ruby thread
by hornairs (Harry Brundage) 17 Aug '26

17 Aug '26

Issue #22248 has been reported by hornairs (Harry Brundage). ---------------------------------------- Bug #22248: `Errno::NOERROR` from `connect(2)` once a non-main Ractor has more than one Ruby thread https://bugs.ruby-lang.org/issues/22248 * Author: hornairs (Harry Brundage) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On `x86_64-linux`, socket IO in a non-main Ractor fails spuriously as soon as that Ractor contains a second Ruby thread. The connecting thread raises `Errno::NOERROR` — errno 0 surfaced as a `SystemCallError`, whose message is literally `Success`: ``` Errno::NOERROR: Failed to open TCP connection to 127.0.0.1:38975 (Success - connect(2) for "127.0.0.1" port 38975) ``` With a raw `TCPSocket` instead of `Net::HTTP` the VM can abort outright: ``` [BUG] rb_sys_fail_path_in(io_fillbuf, fd:6 ) - errno == 0 ``` What the second thread does doesn't seem to matter. A thread that only calls `sleep`, one that only burns CPU, one doing pipe IO, and one doing socket IO all trigger it. Nothing else I varied matters: a Ractor with a single thread never fails, no matter how much socket work it does or how loaded the machine is, and a second thread in the **main** Ractor never causes it, but a second thread in a non-main Ractor does. This bug made my CI jobs flaky in roughly 10% of builds, where the "second thread" was nothing more exotic than a stub HTTP server standing in for an upstream service alongside the client under test. ## Reproduction See this gist: https://gist.github.com/airhorns/dc676921e02272cc41f8aa15da040e45 ``` ruby ractor_factors.rb interleave 200 ``` Note that the interleaving is important to more reliably trigger the bug. On a shared machine the failure rate swings enormously with host load: run in blocks, the same arrangement scored 196/200 in one build and 0/200 in the next, so blocked counts are not comparable to each other and a 0 says nothing. ## Architecture I have only reproduced this on `x86_64-linux`. On `aarch64-linux` — official `ruby:4.0`, byte-identical `revision 03b6d3f889` — roughly 1500 exchanges of the failing arrangements are clean, including 300 of the arrangement that fails 89/200 on x86, under 1- and 2-CPU quotas, with competing busy loops, and with 8 neighbour threads. `arm64-darwin` is clean too. So expect to need an x86_64 Linux host, ideally a loaded one. ## Environment ``` ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] Socket.tcp_fast_fallback = true (default; false reproduces identically) RUBY_MAX_CPU unset (=1 does not help) shared CI host, nproc 16, 1-minute load average 3.1-5.9 during the run ``` ## Relation to Bug #21195 [Bug #21195](https://bugs.ruby-lang.org/issues/21195) is the same shape — errno lost around `io_internal_wait`, fixed for 3.3 and 3.4 in 2025 — and the `errno == 0` assertion text is identical. This is a live path in 4.0.6, reached through ordinary socket connect and read, with or without Happy Eyeballs, so I am filing it separately rather than commenting there. I could not find an existing report for the Ractor variant. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126426] [Ruby Feature#13750] Improve String#casecmp? and Symbol#casecmp? performance with ASCII string
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #13750 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed It was optimized in https://github.com/ruby/ruby/pull/17444 ---------------------------------------- Feature #13750: Improve String#casecmp? and Symbol#casecmp? performance with ASCII string https://bugs.ruby-lang.org/issues/13750#change-118571 * Author: watson1978 (Shizuo Fujita) * Status: Closed ---------------------------------------- I think String#casecmp and String#casecmp? are similar methods. But they have different performance with ASCII strings. It seems that String#casecmp handles ASCII string only, but it is faster than String#casecmp?. This patch uses the code of String#casecmp on String#casecmp? for ASCII strings. However, it introduces a minor penalty for UTF8 strings due to detection of ASCII/UTF8 strings. ~~~ String#casecmp? ASCII -> 61.3 % up String#casecmp? UTF8 -> 1.3 % down Symbol#casecmp? ASCII -> 80.0 % up Symbol#casecmp? UTF8 -> 4.0 % down ~~~ ### Before ~~~ Calculating ------------------------------------- String#casecmp 5.961M (± 3.8%) i/s - 29.838M in 5.017907s String#casecmp? ASCII 3.530M (± 8.6%) i/s - 17.554M in 5.034848s String#casecmp? UTF8 1.252M (± 7.4%) i/s - 6.213M in 5.012168s Symbol#casecmp 8.555M (± 2.4%) i/s - 42.822M in 5.009280s Symbol#casecmp? ASCII 4.235M (± 9.7%) i/s - 20.824M in 5.001368s Symbol#casecmp? UTF8 1.329M (± 0.1%) i/s - 6.704M in 5.043725s ~~~ ### After ~~~ Calculating ------------------------------------- String#casecmp 5.984M (± 6.4%) i/s - 29.829M in 5.020331s String#casecmp? ASCII 5.658M (± 1.5%) i/s - 28.308M in 5.004547s String#casecmp? UTF8 1.215M (± 4.3%) i/s - 6.132M in 5.060292s Symbol#casecmp 8.651M (± 0.9%) i/s - 43.313M in 5.007215s Symbol#casecmp? ASCII 7.462M (± 0.5%) i/s - 37.489M in 5.023892s Symbol#casecmp? UTF8 1.275M (± 0.2%) i/s - 6.444M in 5.052743s ~~~ ### Test code ~~~ruby require 'benchmark/ips' Benchmark.ips do |x| x.report "String#casecmp" do |loop| loop.times { "aBcDeF".casecmp("abcdefg") } end x.report "String#casecmp? ASCII" do |loop| loop.times { "aBcDeF".casecmp?("abcdefg") } end x.report "String#casecmp? UTF8" do |loop| loop.times { "\u{e4 f6 fc}".casecmp?("\u{c4 d6 dc}") } end x.report "Symbol#casecmp" do |loop| loop.times { :aBcDeF.casecmp(:abcdefg) } end x.report "Symbol#casecmp? ASCII" do |loop| loop.times { :aBcDeF.casecmp?(:abcdefg) } end x.report "Symbol#casecmp? UTF8" do |loop| loop.times { :"\u{e4 f6 fc}".casecmp?(:"\u{c4 d6 dc}") } end end ~~~ ### Patch https://github.com/ruby/ruby/pull/1668 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126425] [Ruby Feature#17115] Optimize String#casecmp? for ASCII strings
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #17115 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed It was optimized in https://github.com/ruby/ruby/pull/17444 ---------------------------------------- Feature #17115: Optimize String#casecmp? for ASCII strings https://bugs.ruby-lang.org/issues/17115#change-118570 * Author: byroot (Jean Boussier) * Status: Closed ---------------------------------------- Patch: https://github.com/ruby/ruby/pull/3369 `casecmp?` is a kind of performance trap as it's much slower than using a case insensitive regexp or just `casecmp == 0`. ``` str = "Connection" cmp = "connection" Benchmark.ips do |x| x.report('/\A\z/i.match?') { /\Afoo\Z/i.match?(str) } x.report('casecmp?') { cmp.casecmp?(str) } x.report('casecmp') { cmp.casecmp(str) == 0 } x.compare! end Calculating ------------------------------------- /\A\z/i.match? 11.447M (± 1.3%) i/s - 57.814M in 5.051489s casecmp? 6.197M (± 0.9%) i/s - 31.138M in 5.025252s casecmp 12.753M (± 1.2%) i/s - 64.636M in 5.069195s Comparison: casecmp: 12752791.6 i/s /\A\z/i.match?: 11446996.1 i/s - 1.11x (± 0.00) slower casecmp?: 6196886.0 i/s - 2.06x (± 0.00) slower ``` This is because, unlike the others, it is sensitive to unicode case folding. However, there are cases where fast case insensitive equality check of known ASCII strings is useful. For instance, matching HTTP headers. This patch checks if both strings use a single byte encoding, and if so then does a simple iterative comparison with `TOLOWER()`. This makes `casecmp?` slightly faster than `casecmp == 0` when both strings are ASCII. ``` | |compare-ruby|built-ruby| |:-----------------------|-----------:|---------:| |casecmp-1 | 11.618M| 10.757M| | | 1.08x| -| |casecmp-10 | 1.849M| 1.723M| | | 1.07x| -| |casecmp-100 | 204.490k| 186.798k| | | 1.09x| -| |casecmp-1000 | 20.413k| 20.184k| | | 1.01x| -| |casecmp-nonascii1 | 19.541M| 20.100M| | | -| 1.03x| |casecmp-nonascii10 | 19.489M| 19.914M| | | -| 1.02x| |casecmp-nonascii100 | 19.479M| 20.155M| | | -| 1.03x| |casecmp-nonascii1000 | 19.462M| 20.064M| | | -| 1.03x| |casecmp_p-1 | 2.214M| 12.030M| | | -| 5.43x| |casecmp_p-10 | 1.373M| 2.150M| | | -| 1.57x| |casecmp_p-100 | 249.292k| 231.041k| | | 1.08x| -| |casecmp_p-1000 | 16.173k| 23.592k| | | -| 1.46x| |casecmp_p-nonascii1 | 651.921k| 650.572k| | | 1.00x| -| |casecmp_p-nonascii10 | 108.253k| 109.006k| | | -| 1.01x| |casecmp_p-nonascii100 | 11.749k| 11.889k| | | -| 1.01x| |casecmp_p-nonascii1000 | 1.140k| 1.138k| | ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126424] [Ruby Feature#15458] Automatic Exception#cause print in IRB
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #15458 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed IRB does exactly this now ---------------------------------------- Feature #15458: Automatic Exception#cause print in IRB https://bugs.ruby-lang.org/issues/15458#change-118569 * Author: jnchito (Junichi Ito) * Status: Closed ---------------------------------------- According to Ruby 2.6 NEWS, the following feature will be added: > Print cause of the exception if the exception is not caught and printed its backtraces and error message [Feature #8257] I expected it would be applied in IRB too, but it wasn't. Here is my example: ~~~ > begin > 1/0 > rescue => e > e.mesage > end Traceback (most recent call last): 5: from /Users/jnito/.rbenv/versions/2.6.0-rc1/bin/irb:23:in `<main>' 4: from /Users/jnito/.rbenv/versions/2.6.0-rc1/bin/irb:23:in `load' 3: from /Users/jnito/.rbenv/versions/2.6.0-rc1/lib/ruby/gems/2.6.0/gems/irb-0.9.6/exe/irb:11:in `<top (required)>' 2: from (irb):1 1: from (irb):4:in `rescue in irb_binding' NoMethodError (undefined method `mesage' for #<ZeroDivisionError: divided by 0>) Did you mean? message ~~~ On the other hand, when I run that code via ruby command, cause of the exception is automatically printed: ~~~ $ ruby sample.rb Traceback (most recent call last): 1: from sample.rb:2:in `<main>' sample.rb:2:in `/': divided by 0 (ZeroDivisionError) 1: from sample.rb:1:in `<main>' sample.rb:4:in `rescue in <main>': undefined method `mesage' for #<ZeroDivisionError: divided by 0> (NoMethodError) Did you mean? message ~~~ I feel it would be more natural and useful if the new feature would work in IRB too. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126423] [Ruby Misc#17683] Current status of beginless range (experimental or not)
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #17683 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Certainly not experimental anymore these days ---------------------------------------- Misc #17683: Current status of beginless range (experimental or not) https://bugs.ruby-lang.org/issues/17683#change-118568 * Author: jnchito (Junichi Ito) * Status: Closed ---------------------------------------- A beginless range was experimentally introduced in Ruby 2.7.0: https://github.com/ruby/ruby/blob/v2_7_0/NEWS#label-Other+miscellaneous+cha… Is it still experimental feature or not? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126422] [Ruby Misc#17154] Update Pathname Documentation to Clarify Expected Behavior
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #17154 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed `Pathname#+` docs now mention this https://docs.ruby-lang.org/en/4.0/Pathname.html#method-i-2B > if other is an absolute path, the new Pathname object is created from just other. ---------------------------------------- Misc #17154: Update Pathname Documentation to Clarify Expected Behavior https://bugs.ruby-lang.org/issues/17154#change-118567 * Author: resperat (Ralph Esperat) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- I would like to suggest adding a sentence to the documentation for [Pathname](https://ruby-doc.org/stdlib-2.7.1/libdoc/pathname/rdoc/Pathname.h… to make clear the unusual behavior of `Pathname#+` when an absolute path is included in the arguments. In such a situation, `Pathname#+` drops the paths prior to the last absolute path which I understand to be the intended behavior, but it is not obviously intended, only showing up tangentially as an example in the documentation. ``` p3 = p1 + "/etc/passwd" # Pathname:/etc/passwd ``` The Pathname documentation states that " **All functionality** from File, FileTest, and some from Dir and FileUtils is included, **in an unsurprising way** ..." and later when referring to core methods such as `Pathname#+` "These methods are **effectively manipulating a String** , because that's all a path is." However, similar uses of both [File](https://ruby-doc.org/core-2.7.1/File.html) and [String](https://ruby-doc.org/core-2.7.1/String.html) would produce the expected result of including all of the arguments: ``` s1 = "/usr" s2 = s1 + "/etc/passwd" # "/usr/etc/passwd" f1 = File.new("/usr" + "/etc/passwd") # (No such file or directory @ rb_sysopen - /usr/etc/passwd) ``` A bug report was previously filed to "fix" this functionality (##15564), not understanding it to be intentional. Other common help websites such as [Stack Overflow](https://stackoverflow.com/questions/12464361/concatenating-absolu… also show users who do not expect this behavior from this method. Adding a statement to the documentation for the [Pathname#+](https://ruby-doc.org/stdlib-2.7.1/libdoc/pathname/rdoc/Pathname… method will make it clear to users exactly what to expect and that this is the intended behavior. I would suggest simply the following, the first sentence of which is already present: `Appends a pathname fragment to self to produce a new Pathname object. If an absolute path is provided as any of the arguments, discards all arguments prior to the last absolute path provided.` I appreciate your consideration of this request. ruby -v: ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126421] [Ruby Misc#16659] Documentation on Regexp missing for absence pattern (?~pat)
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #16659 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed It is documented today under https://docs.ruby-lang.org/en/4.0/Regexp.html#class-Regexp-label-Absence+Op… ---------------------------------------- Misc #16659: Documentation on Regexp missing for absence pattern (?~pat) https://bugs.ruby-lang.org/issues/16659#change-118566 * Author: svoop (Sven Schwyn) * Status: Closed ---------------------------------------- The absence pattern `(?~pat)` available since Ruby 2.4.1 is [not yet documented on `Regexp`](https://git.ruby-lang.org/ruby.git/tree/doc/regexp.rdoc) as of today. (Found it by coincidence reading [this article by Peter Cooper](https://medium.com/rubyinside/the-new-absent-operator-in-ruby-s-reg…. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126420] [Ruby Misc#16346] Confusing macro name: RUBY_MARK_NO_PIN_UNLESS_NULL
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #16346 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Seems like this macro has since been renamed/removed ---------------------------------------- Misc #16346: Confusing macro name: RUBY_MARK_NO_PIN_UNLESS_NULL https://bugs.ruby-lang.org/issues/16346#change-118562 * Author: y_kojima (Yohei Kojima) * Status: Closed ---------------------------------------- function `rb_gc_mark_no_pin` is renamed to `rb_gc_mark_movable` in the commit `aac4d9d6c7e6b6b0742f3941b574f6006ccb5672`. But macro `RUBY_MARK_NO_PIN_UNLESS_NULL` is not renamed then. Now, `RUBY_MARK_NO_PIN_UNLESS_NULL` calls `rb_gc_mark_movable`; this is a bit confusing. So I suggest renaming `RUBY_MARK_NO_PIN_UNLESS_NULL` to `RUBY_MARK_MOVABLE_UNLESS_NULL` like this patch. ---Files-------------------------------- p.patch (2 KB) -- https://bugs.ruby-lang.org/

1 0