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

[ruby-core:127172] [Ruby Bug#22454] exited Ractors' memory is reclaimed only by a global GC, so memory grows without bound.
by matteo.folin＠gmail.com (Matteo Folin) 19 Oct '26

19 Oct '26

Issue #22454 has been reported by matteo.folin(a)gmail.com (Matteo Folin). ---------------------------------------- Bug #22454: exited Ractors' memory is reclaimed only by a global GC, so memory grows without bound. https://bugs.ruby-lang.org/issues/22454 * Author: matteo.folin(a)gmail.com (Matteo Folin) * Status: Open * ruby -v: 4.1.0-preview1 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- - 8 rounds of 1,000 short-lived Ractors on 4.1.0-preview1: RSS climbs from 159 MB to 1,125 MB, with a single global GC. - With a GC.start after each round, it stops at ~435 MB. - On 4.0.7 it stays at 34–44 MB. - It tells the server story: OOM-killed in 8 GB once the first sockets closed. - It asks for a trigger based on the exited Ractors still waiting to be reclaimed, and notes that even 435 MB is ~10× 4.0's figure. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120579] [Ruby master Feature#21020] Sync sig directory for prism of default gem.
by ksss (Yuki Kurihara) 19 Oct '26

19 Oct '26

Issue #21020 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Feature #21020: Sync sig directory for prism of default gem. https://bugs.ruby-lang.org/issues/21020 * Author: ksss (Yuki Kurihara) * Status: Open ---------------------------------------- Currently, the type signatures (RBS) for the default gem is not available. **Prism** is the only default gem with type signatures, but this number is expected to increase in the future. As a first step to resolving this issue, I propose including the `sig` directory of Prism as a default gem in the synchronization process. PR: https://github.com/ruby/ruby/pull/12541 -- https://bugs.ruby-lang.org/

5 7

[ruby-core:126900] [Ruby Feature#22400] Use rb_long_t for lengths so that String and Array can exceed 2GiB on mswin
by hsbt (Hiroshi SHIBATA) 19 Oct '26

19 Oct '26

Issue #22400 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #22400: Use rb_long_t for lengths so that String and Array can exceed 2GiB on mswin https://bugs.ruby-lang.org/issues/22400 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- On x64-mswin64, `long` is 32 bits while pointers are 64 bits. String, Array and MatchData keep their lengths in `long`, so none of them can reach 2GiB. ```ruby "a" * 2**31 # RangeError: bignum too big to convert into 'long' File.open(path, "rb") { it.read(2**31) } # RangeError Array.new(2**31) # RangeError ``` I propose giving these lengths and indices a type of their own, `rb_long_t`, in two steps. The first step is https://github.com/ruby/ruby/pull/18862. It defines `typedef long rb_long_t` everywhere and uses it for the lengths and indices of RString, RArray and RMatch, the C API that carries them, and the core, adding `LONGT2NUM`, `NUM2LONGT` and `PRIdLONGT`. A static assert keeps it `long`, so nothing changes, and `NUM2LONG` and `FIX2LONG` still return `long`. The second step makes `rb_long_t` 64 bits on mswin, as `rb_off_t` already does for `off_t` there. mingw keeps `long`, and Fixnum (#14378) stays as is. This breaks extensions that pass a `long *` to an out-parameter such as `rb_range_beg_len`, because Ruby then writes 8 bytes into a 4-byte variable. `-we4133` makes that a compile error, and I will send fixes to the gems it hits: nokogiri, google-protobuf, nokolexbor, string_view, readline-ext and iconv. An extension supporting older Ruby can `typedef long rb_long_t` when `RB_LONGT_MAX` is undefined. No existing type fits. `ssize_t` and `intptr_t` are `int` on ILP32 and would change `long *` parameters there. `SIGNED_VALUE` is already 64 bits on mswin, so it could not land as a no-op first. To catch new code that adds a plain `long` for a length, I would like a CI job that builds with `rb_long_t` set to `long long` on Linux, where `%ld` and `long *` mismatches fail. First, do you agree with this direction and with carrying it out? If so, is `rb_long_t` a good name? And since few C extensions are distributed for mswin, I think we could make the second step in 4.1 as well, without a transition period. What do you think? -- https://bugs.ruby-lang.org/

5 12

[ruby-core:126555] [Ruby Bug#22286] Closing a TCPServer while another thread is blocked in accept can discard a just-accepted connection's file descriptor, leaving the peer connected to nothing
by docelic (Davor Ocelic) 18 Oct '26

18 Oct '26

Issue #22286 has been reported by docelic (Davor Ocelic). ---------------------------------------- Bug #22286: Closing a TCPServer while another thread is blocked in accept can discard a just-accepted connection's file descriptor, leaving the peer connected to nothing https://bugs.ruby-lang.org/issues/22286 * Author: docelic (Davor Ocelic) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Closing a TCPServer while another thread is blocked in accept can discard a just-accepted connection's file descriptor, leaving the peer connected to nothing. The script to reproduce the issue in each iteration binds a listener, starts a thread blocked in accept, connects a client, then tears the listener down in one of three orders. It then closes whatever the accept thread actually received and checks whether the client sees the peer go away within half a second. After a GC it reports how many descriptors the process still holds beyond its starting count. Results on Ruby 4.0.6, Linux 6.18. ``` ┌─────────────────────┬─────────────────────┬─────────────────────┐ │ mode │ stuck clients / 300 │ leaked fds after GC │ ├─────────────────────┼─────────────────────┼─────────────────────┤ │ close │ 89 │ 89 │ ├─────────────────────┼─────────────────────┼─────────────────────┤ │ shutdown │ 127 │ 127 │ ├─────────────────────┼─────────────────────┼─────────────────────┤ │ shutdown-join-close │ 0 │ 0 │ └─────────────────────┴─────────────────────┴─────────────────────┘ ``` Every stuck client is one the accept thread never handed back, and the leaked descriptor count matches. So accept(2) returned a socket, but Ruby raised the "closed in another thread" interrupt in that thread before wrapping the descriptor, and the descriptor was dropped. Joining the accept thread before calling close avoids the issue. Run the script with: ``` # The number of issue occurrences will be reported in hang/not-accepted/fd-delta value. ruby accept_race.rb close # issue visible ruby accept_race.rb shutdown # confirms issue coming from close-interrupt ruby accept_race.rb shutdown-join-close # workaround to fix the issue ``` ---Files-------------------------------- tcpserver-close-bug.rb (759 Bytes) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126989] [Ruby Bug#22414] YJIT: arm64 panic "should not fail when writing to a fresh code page" when the code region fills at a page boundary — please backport 5a7089fc03fb to 3.4
by hank (Hank Gay) 18 Oct '26

18 Oct '26

Issue #22414 has been reported by hank (Hank Gay). ---------------------------------------- Bug #22414: YJIT: arm64 panic "should not fail when writing to a fresh code page" when the code region fills at a page boundary — please backport 5a7089fc03fb to 3.4 https://bugs.ruby-lang.org/issues/22414 * Author: hank (Hank Gay) * Status: Open * ruby -v: ruby 3.3.12 (2026-07-16 revision 0581089df9) [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- On aarch64-linux, YJIT aborts the whole process when the code region runs out of space at a page boundary. This was fixed on master by ruby/ruby@5a7089fc03fb ("YJIT: A64: Remove assert that trips when OOM at page boundary", GitHub PR #12668, originally reported in Shopify/ruby#566 against 3.4.1). The fix shipped in 4.0.0, but it was never backported. The assert is still present on the `ruby_3_4` branch head and in v3_4_11, and on `ruby_3_3` / v3_3_12. ## Impact We run Rails under Puma with YJIT on AWS Fargate Graviton (aarch64). On the first day of production traffic, this panic killed 43 Puma workers, and each one dropped its in-flight requests. A replacement worker fills its code region again and panics 12-20 minutes later, so the crashes keep recurring and never settle down. We had to disable YJIT on aarch64. x86_64 is not affected. The key lines from our logs are: YJIT has panicked ... yjit/src/backend/arm64/mod.rs:1250 assertion `left != right` failed: should not fail when writing to a fresh code page left: Err(RetryOnNextPage) ## Request Please backport 5a7089fc03fb to `ruby_3_4`. The commit applies cleanly to v3_4_11 (`git apply --check`). It is a small, local change: the assert becomes an `Err(EmitError::OutOfMemory)` return, which the caller already handles, and `#[must_use]` is added to `CodeBlock::next_page`. I understand 3.3 is in security maintenance, so a 3.3 backport is probably out of scope. For the record, the same commit applies to v3_3_12 with only line offsets, and the patched YJIT crate compiles. If an exception is possible for a crash that takes down the whole process, we would appreciate it. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:127118] [Ruby Bug#22445] On macOS, a child of Kernel#fork can abort with "[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)"
by dug (Doug E) 17 Oct '26

17 Oct '26

Issue #22445 has been reported by dug (Doug E). ---------------------------------------- Bug #22445: On macOS, a child of Kernel#fork can abort with "[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)" https://bugs.ruby-lang.org/issues/22445 * Author: dug (Doug E) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin23] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- SUBJECT: On macOS, a child of Kernel#fork can abort with "[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)" TRACKER: Bug ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin23] --- On macOS, `Kernel#fork` can abort the child with `[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)` when another thread is waiting for the fork lock at the moment of the fork. getaddrinfo helper threads take that lock for reading (Feature #20590), and since [Bug #22406] getnameinfo helper threads do too, so a process that resolves names in background threads while it forks loses a child now and then. ## Reproduction ```ruby require "socket" # Threads that keep resolving names, so that one is often waiting for the # fork lock while a fork holds it. 6.times { Thread.new { loop { Addrinfo.getaddrinfo("localhost", 80, :INET, :STREAM) } } } aborted = 0 1000.times do _, status = Process.wait2(fork { exit!(0) }) aborted += 1 unless status.success? end puts "#{RUBY_DESCRIPTION}: #{aborted} of 1000 children aborted" ``` On macOS 27.0.1 (arm64), every aborted child printed `[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)`, with `rb_thread_reset_fork_lock` under `rb_fork_ruby` in its backtrace: ``` ruby 3.4.11 (2026-09-23 revision 592f1ffdb3) +PRISM [arm64-darwin23]: 3 of 1000 children aborted ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin23]: 4 of 1000 children aborted ``` No network is needed: `localhost` comes from /etc/hosts. ## Analysis `rb_fork_ruby` takes the fork lock for writing, forks, and the child calls `rb_thread_release_fork_lock()` and then `rb_thread_reset_fork_lock()`, which destroys the lock and initializes it again. A thread that calls `rb_thread_prevent_fork()` while the fork holds the lock blocks in `pthread_rwlock_rdlock()`. That thread does not exist in the child, but macOS's lock counts its waiters, and the child's copy still counts it, so `pthread_rwlock_destroy()` returns EBUSY and `rb_bug_errno()` aborts. `pthread_rwlock_init()` returns EBUSY as well. This C program shows it without Ruby. With a thread waiting for the read lock at the fork, both calls fail in the child; without one, both succeed. Assigning `PTHREAD_RWLOCK_INITIALIZER` works either way. ```c #include <pthread.h> #include <stdio.h> #include <string.h> #include <sys/wait.h> #include <unistd.h> static pthread_rwlock_t lock = PTHREAD_RWLOCK_INITIALIZER; static void * reader(void *arg) { pthread_rwlock_rdlock(&lock); // blocks: main holds the write lock pthread_rwlock_unlock(&lock); return NULL; } int main(void) { pthread_t th; pthread_rwlock_wrlock(&lock); pthread_create(&th, NULL, reader, NULL); usleep(100000); // let it block in rdlock if (fork() == 0) { int u = pthread_rwlock_unlock(&lock); int d = pthread_rwlock_destroy(&lock); int i = pthread_rwlock_init(&lock, NULL); printf("unlock=%s destroy=%s init=%s\n", u ? strerror(u) : "ok", d ? strerror(d) : "ok", i ? strerror(i) : "ok"); fflush(stdout); _exit(0); } wait(NULL); pthread_rwlock_unlock(&lock); pthread_join(th, NULL); } ``` ``` unlock=ok destroy=Resource busy init=Resource busy ``` glibc's `pthread_rwlock_destroy()` does not check the lock, so Linux is not affected. c8155822c4 ([Bug #21959]) hit the same problem with `rb_internal_thread_event_hooks_rw_lock` and reinitializes it in the child by assigning `PTHREAD_RWLOCK_INITIALIZER`; it was backported to 3.4 and 4.0. The fork lock was added with `rb_thread_reset_fork_lock()` in 63cbe3f6ac (Feature #20590), so 3.4 and later are affected. ## Fix I will open a pull request for this ticket. In the child, it resets the fork lock by assigning `PTHREAD_RWLOCK_INITIALIZER` and no longer unlocks the child's copy first. Assigning after the unlock is not enough on macOS: with a waiter counted, the unlock goes into the kernel to wake it, and the state that leaves for the lock's address survives the assignment, so a later waiter in the child can sleep forever although no thread holds the lock. FreeBSD already skips that unlock in the child (dc8c382266), and on glibc it leaves the lock write-locked anyway, so the child can skip it on every platform. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:127151] [Ruby Bug#22451] Coderange may be set incorrectly when concatenating a string into itself
by jhawthorn (John Hawthorn) 17 Oct '26

17 Oct '26

Issue #22451 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22451: Coderange may be set incorrectly when concatenating a string into itself https://bugs.ruby-lang.org/issues/22451 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby s = "\x81\x30".force_encoding("GB18030") #=> "\x810" s.valid_encoding? # This is invalid #=> false (s + s).valid_encoding? # However it becomes valid when repeated #=> true (s << s).valid_encoding? # But concat assumed the coderange would not change #=> false s.b.force_encoding(s.encoding).valid_encoding? # Same bytes, different answer #=> true ``` https://github.com/ruby/ruby/pull/19357 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126921] [Ruby Bug#22406] Process.fork can leave the child unable to resolve hostnames: getaddrinfo helper threads take glibc's resolver lock after releasing the fork lock
by dug (dug e) 17 Oct '26

17 Oct '26

Issue #22406 has been reported by dug (dug e). ---------------------------------------- Bug #22406: Process.fork can leave the child unable to resolve hostnames: getaddrinfo helper threads take glibc's resolver lock after releasing the fork lock https://bugs.ruby-lang.org/issues/22406 * Author: dug (dug e) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- On Linux with glibc, a process forked while another thread's `getaddrinfo` helper pthread is exiting can inherit glibc's resolver-configuration lock in the locked state. Every hostname lookup in the child then blocks forever. Feature #20590 keeps fork out of the `getaddrinfo(3)` call itself, but the helper releases that protection before its thread exit takes the same lock. This is not the macOS problem in #21790, #21876 and #21969. Those are a crash in Apple's resolver that every child hits after any lookup in the parent. This one is on Linux with glibc. It is a race with another thread's lookup, and the child waits on a lock forever rather than crashing. ## Reproduce process Reproduced with each of these, in the official `ruby:<version>-slim` images (Debian, glibc 2.41, aarch64): ``` ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [aarch64-linux] ruby 3.4.11 (2026-09-23 revision 592f1ffdb3) +PRISM [aarch64-linux] ``` master ([dbabf7d789](https://github.com/ruby/ruby/tree/dbabf7d78994c6ab50cee24fa85bf…) has the same code: [`rb_thread_prevent_fork`](https://github.com/ruby/ruby/blob/dbabf7d78994c6ab50cee24fa85bf7d68a14fe66/thread_pthread.c#L1496-L1505) still releases the fork lock before the helper returns, and the helpers are still wrapped at [raddrinfo.c L552](https://github.com/ruby/ruby/blob/dbabf7d78994c6ab50cee24fa85bf7d68a1… and [L3193](https://github.com/ruby/ruby/blob/dbabf7d78994c6ab50cee24fa85bf7d68a…. No network is needed. The background lookups and the probe both resolve `localhost` from `/etc/hosts`. ```ruby require "socket" # Threads that keep resolving a hostname, as an HTTP poller in the parent would. 4.times do Thread.new do loop do Addrinfo.getaddrinfo("localhost", 80, nil, :STREAM) Thread.pass end end end sleep 0.5 hung = 0 20_000.times do reader, writer = IO.pipe pid = fork do reader.close lookup = Thread.new { Addrinfo.getaddrinfo("localhost", 80, :INET, :STREAM) } writer.write(lookup.join(2) ? "ok" : "hung") exit!(0) end writer.close hung += 1 if reader.read == "hung" reader.close Process.wait(pid) end puts "#{RUBY_DESCRIPTION}: #{hung} of 20000 children could not resolve localhost" ``` As a control, change the background threads to resolve `"127.0.0.1"`. That address never reaches `getaddrinfo(3)`, so no helper thread is started. ## Result Runs on aarch64 Linux in Docker: | Ruby | Background threads resolve | Children that could not resolve, per run of 20,000 forks | | --- | --- | --- | | 4.0.7 | `localhost` | 6, 3 | | 4.0.7 | `127.0.0.1` (control) | 0 | | 3.4.11 | `localhost` | 3, 2 | | 3.4.11 | `127.0.0.1` (control) | 0 | This is the stack of the stuck helper thread in a hung child, from `eu-stack` with `libc6-dbg` installed (3.4.10, glibc 2.41): ``` #0 __lll_lock_wait_private #1 get_locked_global #2 __resolv_conf_get_current #3 __res_vinit #4 maybe_init #5 __resolv_context_get #6 gethostbyname2_r@@GLIBC_2.17 #7 getaddrinfo #8 do_getaddrinfo #9 rb_thread_prevent_fork #10 start_thread #11 thread_start ``` The futex it waits on resolves to libc's static `lock` (libc+0x1b7dd8 in that build), the lock `get_locked_global` takes. ## Expected result Every child resolves `localhost`, as every child does in the control runs. Feature #20590 made fork wait for in-flight `getaddrinfo` calls so that a child cannot inherit a resolver lock held by another thread. A child should not inherit one from the part of a helper thread's life that comes after the call either. ## Analysis - Each helper thread's start routine runs `getaddrinfo(3)` inside `rb_thread_prevent_fork`, which holds `rb_thread_fork_rw_lock` for reading. `rb_fork_ruby` takes that lock for writing. - The read lock is released as soon as `getaddrinfo` returns. Then the helper thread exits, and glibc's thread exit takes the resolver lock: - `start_thread` calls `__libc_thread_freeres`, - which calls `__res_thread_freeres` and then `__res_iclose(&_res, true)`, - which calls `__resolv_conf_detach`, - which calls `get_locked_global`, locking the static `lock` in `resolv/resolv_conf.c`. - glibc's `fork` resets the malloc, stdio, NSS and dynamic loader locks in the child, but not this one. So a fork that runs after `rb_thread_release_fork_lock()` in the helper, and before the helper's thread exit releases the resolver lock, copies that lock held by a thread that does not exist in the child. The only resolver callers in the reproduction are Ruby's own helper threads, and the fork lock keeps fork out of their `getaddrinfo` calls. So the lock the child inherited was held by a helper thread that was exiting. The window is probably hit more often than its size suggests (inference). When `Process.fork` arrives while a helper is inside `getaddrinfo`, `rb_thread_acquire_fork_lock` blocks. The helper's `pthread_rwlock_unlock` then wakes it just as that same helper moves on to exit and take the resolver lock. Ruby keeps the waiting Ruby thread interruptible, so `Timeout` and `resolv_timeout` still fire. Lookups of IP literals still work, because they never reach `getaddrinfo(3)`. So in practice every new connection by hostname times out for the life of the process. Source: - Ruby at v3_4_11; v4.0.7 and master have the same structure, see the master links above: - [raddrinfo.c L525](https://github.com/ruby/ruby/blob/v3_4_11/ext/socket/raddrinfo.c#L525) and [L3161](https://github.com/ruby/ruby/blob/v3_4_11/ext/socket/raddrinfo.c#L31… - [thread_pthread.c L3329-L3338](https://github.com/ruby/ruby/blob/v3_4_11/thread_pthread.c#L33… - [process.c L4236](https://github.com/ruby/ruby/blob/v3_4_11/process.c#L4236) - glibc 2.41, the version in the reproduction. 2.35 has the same code on these paths. - [nptl/pthread_create.c L459](https://github.com/bminor/glibc/blob/glibc-2.41/nptl/pthread_create.c…: `start_thread` calls `__libc_thread_freeres`. - [malloc/thread-freeres.c L35](https://github.com/bminor/glibc/blob/glibc-2.41/malloc/thread-freeres.…: that calls `__res_thread_freeres`. - [resolv/res-close.c L129-L142](https://github.com/bminor/glibc/blob/glibc-2.41/resolv/res-close… and [L117](https://github.com/bminor/glibc/blob/glibc-2.41/resolv/res-close.c#L1…: `__res_iclose(&_res, true)` calls `__resolv_conf_detach`. - [resolv/resolv_conf.c L81](https://github.com/bminor/glibc/blob/glibc-2.41/resolv/resolv_conf.c#L… defines `lock`. [L648](https://github.com/bminor/glibc/blob/glibc-2.41/resolv/resolv_conf.c#… takes it at thread exit, and [L130](https://github.com/bminor/glibc/blob/glibc-2.41/resolv/resolv_conf.c#… is where the child waits. - [posix/fork.c L88-L108](https://github.com/bminor/glibc/blob/glibc-2.41/posix/fork.c#L88-…: the locks fork resets in the child. ## Impact This affects preforking servers whose parent process runs background threads that connect by hostname. We found it in a Pitchfork deployment. A feature-flag SDK in the parent polls an HTTP endpoint every 30 seconds, and roughly one in tens of thousands of forked workers comes up unable to open any connection by hostname. Pitchfork's documentation for `Pitchfork.prevent_fork` warns about `getaddrinfo(3)` in background threads. ## Possible directions These are not patches, just the options I considered: - **Wait for helpers to finish exiting.** Keep fork out until helper threads have exited, not only until they have finished `getaddrinfo`. For example, fork could join helpers that have returned but not yet exited, though today the helpers are detached. - **Reuse resolver threads.** Keep a small pool instead of exiting after each lookup, so the detach that runs at thread exit happens only at process exit. glibc could also reset this lock in the child, as it does the NSS locks. But glibc's position is that only async-signal-safe functions are supported in the child of a multithreaded process. ## Workaround - Avoid hostname lookups in background threads of a process that forks, or wrap them so the fork waits until the thread is fully idle. - To contain the damage, check resolution in the child after fork and exit if it hangs. For example, run `Addrinfo.getaddrinfo("localhost", 80, :INET, :STREAM)` in a thread and join it with a short timeout. cc @byroot (Feature #20590), @mame (Feature #19965), @shioimm (the Happy Eyeballs `getaddrinfo` helper) -- https://bugs.ruby-lang.org/

6 22

[ruby-core:126992] [Ruby Bug#22415] Thread.handle_interrupt needs to preserve errinfo
by rwstauner (Randy Stauner) 17 Oct '26

17 Oct '26

Issue #22415 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22415: Thread.handle_interrupt needs to preserve errinfo https://bugs.ruby-lang.org/issues/22415 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Thread.handle_interrupt checks for interrupts after its block has returned but before re-raising the break/return that left the block. A signal trap that runs in that window clears ec->errinfo, which is where the throw data for the pending break/return lives, so the VM throws nil. This small script reproduces the SEGV very quickly: ```ruby trap(:USR1) { raise "boom" rescue nil } pid = $$ killer = fork { (Process.kill(:USR1, pid); sleep 0.001) while Process.ppid == pid } 1_000_000.times { Thread.handle_interrupt(Exception => :immediate) { break } } Process.kill(:KILL, killer) puts "no crash" ``` -- https://bugs.ruby-lang.org/

2 6

[ruby-core:127084] [Ruby Bug#22432] Range#include? returns true for the end of an empty range of single-character Strings
by sferik (Erik Berlin) 16 Oct '26

16 Oct '26

Issue #22432 has been reported by sferik (Erik Berlin). ---------------------------------------- Bug #22432: Range#include? returns true for the end of an empty range of single-character Strings https://bugs.ruby-lang.org/issues/22432 * Author: sferik (Erik Berlin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A Range whose ends are both single ASCII characters reports that it includes its end even when the range is empty. ```ruby r = "z".."a" r.to_a #=> [] r.include?("a") #=> true r.member?("a") #=> true r.cover?("a") #=> false r === "a" #=> false ``` I expect `include?` and `member?` to return false here, as `cover?` does and as iterating the range implies. The same happens with digits, for example `("1".."0").include?("0")`. Only the end is affected. Other values are correctly reported as not included: ```ruby ("z".."a").include?("z") #=> false ("z".."a").include?("m") #=> false ``` `Range#include?` has a shortcut for ranges of single-character Strings, which compares the characters instead of iterating. It is in `rb_str_include_range_p` in string.c: ```c if (ISASCII(b) && ISASCII(e) && ISASCII(v)) { if (b <= v && v < e) return Qtrue; return RBOOL(!RTEST(exclusive) && v == e); } ``` The last line returns true whenever the value equals the end, without checking that the begin is not after the end. -- https://bugs.ruby-lang.org/

3 4