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

[ruby-core:126158] [Ruby Bug#22211] Fiber::Scheduler stalls on Ractor::Port.receive
by rkh (Konstantin Haase) 19 Aug '26

19 Aug '26

Issue #22211 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22211: Fiber::Scheduler stalls on Ractor::Port.receive https://bugs.ruby-lang.org/issues/22211 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-24T12:18:38Z master 180b664bd9) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Quickly upfront: This might be a duplicate of #20276, and let me know if the official solution is still to launch a thread for each port so it can block (or add some more complex thread orchestration). Anyway, I think `Ractor::Port#receive` should call `Fiber::Scheduler#block`/`Fiber::Scheduler#unblock` if a scheduler is set (or some other hook), the way that `Thread::Queue` does. Instead, it completely blocks the scheduler. Example to reproduce: ``` ruby Warning[:experimental] = false class Scheduler def initialize @fiber = Fiber.current @blocked = Set.new @ready = Queue.new end def scheduler_close @ready.pop.transfer while @blocked.any? end def block(blocker, timeout = nil) raise NotImplementedError, "block: timeout not supported" if timeout @blocked << Fiber.current @fiber.transfer ensure @blocked.delete(Fiber.current) end def unblock(blocker, fiber) = @ready << fiber def io_write(io, buffer, offset, length) = Thread.new { buffer.write(io, offset, length) }.value def fiber(&) = Fiber.new(blocking: false, &).tap(&:transfer) def respond_to_missing?(...) = true def method_missing(method, ...) = raise NotImplementedError, "#{method}: not implemented" end Fiber.set_scheduler(Scheduler.new) # This would work: # # queue = Queue.new # Fiber.schedule { puts queue.pop } # queue.push "Hello from Queue!" port = Ractor::Port.new Fiber.schedule { puts port.receive } port.send("Hello from Ractor::Port!") # never gets here ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126156] [Ruby Bug#22210] Check if issue #19969 is still reproducible / re-opened in 4.0.x
by saka_omo (Yuki Takei) 18 Aug '26

18 Aug '26

Issue #22210 has been reported by saka_omo (Yuki Takei). ---------------------------------------- Bug #22210: Check if issue #19969 is still reproducible / re-opened in 4.0.x https://bugs.ruby-lang.org/issues/22210 * Author: saka_omo (Yuki Takei) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi team, I am writing to ask if Bug #19969 might still be reproducible in the current version of Ruby. Could you please check if the issue is still present or if a regression has occurred? I ran the reproduction script from #19969 across several Ruby versions on macOS (arm64-darwin), and while Ruby 3.2.4 fixed the high memory consumption (dropping to 29 MiB), Ruby 4.0.5 spikes back up to 2215 MiB. ``` ruby ruby -v -rset -e 's1 = Set.new(10000.times); s2 = Set.new(9999.times); Array.new(10000) { s1 - s2 - [0] }; puts "#{`ps -o rss= -p #{$$}`.to_i / 1024} MiB"' ``` Results across versions: ``` ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [arm64-darwin22] 183 MiB ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] 2364 MiB ruby 3.2.4 (2024-04-23 revision af471c0e01) [arm64-darwin22] 29 MiB ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin24] 2215 MiB ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126198] [Ruby Bug#22217] Segmentation fault when resuming execution with `Coverage.start` and ruby/debug
by yokomaru (Yoko Suzuki) 18 Aug '26

18 Aug '26

Issue #22217 has been reported by yokomaru (Yoko Suzuki). ---------------------------------------- Bug #22217: Segmentation fault when resuming execution with `Coverage.start` and ruby/debug https://bugs.ruby-lang.org/issues/22217 * Author: yokomaru (Yoko Suzuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-29T23:49:57Z master 94933bfebf) +PRISM [arm64-darwin25],ruby 4.1.0dev (2026-07-29T23:49:57Z master 94933bfebf) +PRISM [x86_64-linux],ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25],ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Resuming execution from `ruby/debug` while coverage collection is enabled via `Coverage.start` can cause a segmentation fault and crash the Ruby process. The crash is intermittent, but reproduces frequently using the same steps. I confirmed it on both macOS (arm64) and Linux (x86_64) using debug 1.11.1. It reproduced with Ruby 4.0.5, Ruby 4.0.6, and Ruby 4.1.0-dev, but did not reproduce in my limited testing with Ruby 3.4.10 or Ruby 3.3.12. ## Reproduction Code `test.rb` ```ruby require "coverage" Coverage.start require "debug" debugger ``` ## Steps to Reproduce Run: ```console $ ruby test.rb ``` At the debugger prompt, enter: ```text continue ``` The same crash also occurs with `next`, `step`, and `finish`. ## Backtrace Excerpt Both macOS and Linux crash around the Ruby VM event hooks. On macOS (arm64), the C-level backtrace includes: ```text libruby.4.1.dylib(exec_hooks_protected+0xb0) libruby.4.1.dylib(rb_exec_event_hooks+0x7c) libruby.4.1.dylib(vm_trace_hook+0x198) libruby.4.1.dylib(vm_trace+0x24c) ``` On Linux (x86_64), it includes: ```text libruby.so.4.1(exec_hooks_body+0x20) vm_trace.c:453 libruby.so.4.1(exec_hooks_protected+0x10b) vm_trace.c:515 libruby.so.4.1(rb_exec_event_hooks+0x83) vm_trace.c:562 libruby.so.4.1(vm_trace_hook+0x17c) vm_core.h:2376 libruby.so.4.1(vm_trace+0x344) vm_insnhelper.c:7373 ``` I've attached the crash log from the latest version (4.1.0-dev). ---Files-------------------------------- test.rb (62 Bytes) stderr-macos-4.1-dev.log (35.7 KB) stderr-linux-4.1-dev.log (35.4 KB) ruby-2026-07-30-112302.ips (15 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125979] [Ruby Bug#22188] Debug symbols missing when compiled with GCC LTO
by rwstauner (Randy Stauner) 18 Aug '26

18 Aug '26

Issue #22188 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22188: Debug symbols missing when compiled with GCC LTO https://bugs.ruby-lang.org/issues/22188 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When compiling with LTO (the XCFLAGS and XLDFLAGS below) RUBY_CRASH_REPORT does not resolve symbols. ( export optflags="-O3" cflags="-fno-omit-frame-pointer" export XCFLAGS="-flto=auto -ffat-lto-objects -Werror=lto-type-mismatch" export XLDFLAGS="-flto=auto -ffat-lto-objects" ./configure --disable-install-doc --disable-shared make -j miniruby ) Simple crash simulation: ./miniruby -e 'Process.kill("SEGV", $$)' On master the output includes: -- C level backtrace information ------------------------------------------- /src/miniruby(0x5608c71bafdd) [0x5608c71bafdd] /src/miniruby(0x5608c71c6f46) [0x5608c71c6f46] /src/miniruby(0x5608c6f31370) [0x5608c6f31370] /src/miniruby(0x5608c70e3150) [0x5608c70e3150] /usr/lib/libc.so.6(0x7f62122ac2d0) [0x7f62122ac2d0] /usr/lib/libc.so.6(kill+0xb) [0x7f62122ac4db] /src/miniruby(0x5608c70e1a65) [0x5608c70e1a65] /src/miniruby(0x5608c7189d1e) [0x5608c7189d1e] /src/miniruby(0x5608c718dea7) [0x5608c718dea7] /src/miniruby(0x5608c719417e) [0x5608c719417e] /src/miniruby(0x5608c71b793c) [0x5608c71b793c] /src/miniruby(0x5608c6f3d13c) [0x5608c6f3d13c] /src/miniruby(0x5608c6f42321) [0x5608c6f42321] /src/miniruby(0x5608c6e4f9b3) [0x5608c6e4f9b3] /usr/lib/libc.so.6(0x7f62122956c1) [0x7f62122956c1] /usr/lib/libc.so.6(__libc_start_main+0x89) [0x7f62122957f9] [0x5608c6e4f9f5] With a tiny change to fall back to symtab (even after parsing DWARF) we can get (empty lines added for comparison with next block): -- C level backtrace information ------------------------------------------- /src/miniruby(rb_print_backtrace+0x1d) [0x55f6397aafdd] /src/vm_dump.c:1111 /src/miniruby(rb_vm_bugreport+0xa26) [0x55f6397b6f46] /src/vm_dump.c:1473 /src/miniruby(rb_bug_for_fatal_signal+0x110) [0x55f639521370] /src/error.c:1140 /src/miniruby(sigsegv+0x50) [0x55f6396d3150] /src/signal.c:948 /usr/lib/libc.so.6(0x7f991555d2d0) [0x7f991555d2d0] /usr/lib/libc.so.6(kill+0xb) [0x7f991555d4db] /src/miniruby(rb_f_kill+0x205) [0x55f6396d1a65] /src/signal.c:487 /src/miniruby(vm_call_cfunc_with_frame_+0xfe) [0x55f639779d1e] /src/vm_insnhelper.c:3821 /src/miniruby(vm_sendish.constprop.0+0xb7) [0x55f63977dea7] /src/vm_insnhelper.c:6056 /src/miniruby(vm_exec_core.lto_priv.0+0x6e) [0x55f63978417e] /src/insns.def:909 /src/miniruby(rb_vm_exec+0xec) [0x55f6397a793c] /src/vm.c:2825 /src/miniruby(rb_ec_exec_node+0xac) [0x55f63952d13c] /src/eval.c:284 /src/miniruby(ruby_run_node+0x61) [0x55f639532321] /src/eval.c:322 /src/miniruby(main+0x63) [0x55f63943f9b3] ./main.c:42 PR: https://github.com/ruby/ruby/pull/17743 Currently the code in addr2line.c has a stub: case DW_FORM_ref_addr: goto finish; /* not supported yet */ If we add support for that we can get better names and inlined frames (empty lines added for comparison with previous block): -- C level backtrace information ------------------------------------------- /src/miniruby(rb_print_backtrace+0x1d) [0x55cd045f81dd] /src/vm_dump.c:1111 /src/miniruby(fprintf+0x0) [0x55cd04604146] /src/vm_dump.c:1473 /src/miniruby(rb_vm_bugreport) /src/vm_dump.c:1476 /src/miniruby(rb_bug_for_fatal_signal+0x110) [0x55cd0436e370] /src/error.c:1140 /src/miniruby(sigsegv+0x50) [0x55cd04520150] /src/signal.c:948 /usr/lib/libc.so.6(0x7f9ef85522d0) [0x7f9ef85522d0] /usr/lib/libc.so.6(kill+0xb) [0x7f9ef85524db] /src/miniruby(rb_f_kill+0x205) [0x55cd0451ea65] /src/signal.c:487 /src/miniruby(vm_call_cfunc_with_frame_+0xfe) [0x55cd045c6f1e] /src/vm_insnhelper.c:3821 /src/miniruby(vm_sendish+0xb7) [0x55cd045cb0a7] /src/vm_insnhelper.c:6056 /src/miniruby(vm_exec_core+0x6e) [0x55cd045d137e] /src/insns.def:909 /src/miniruby(vm_exec_loop+0x16) [0x55cd045f4b3c] /src/vm.c:2825 /src/miniruby(rb_vm_exec) /src/vm.c:2801 /src/miniruby(rb_ec_exec_node+0xac) [0x55cd0437a13c] /src/eval.c:284 /src/miniruby(ruby_run_node+0x61) [0x55cd0437f321] /src/eval.c:322 /src/miniruby(rb_main+0x22) [0x55cd0428c9b3] ./main.c:42 /src/miniruby(main) ./main.c:62 /usr/lib/libc.so.6(0x7f9ef853b6c1) [0x7f9ef853b6c1] /usr/lib/libc.so.6(__libc_start_main+0x89) [0x7f9ef853b7f9] /src/miniruby(_start+0x25) [0x55cd0428c9f5] ./main.c:63 PR: https://github.com/ruby/ruby/pull/17744 -- https://bugs.ruby-lang.org/

3 3

[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