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

[ruby-core:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 11 Mar '26

11 Mar '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124655] [Ruby Bug#21856] Nokogiri performance degradation since Ruby 4.0
by ahorek 11 Mar '26

11 Mar '26

Issue #21856 has been reported by ahorek (Pavel Rosický). ---------------------------------------- Bug #21856: Nokogiri performance degradation since Ruby 4.0 https://bugs.ruby-lang.org/issues/21856 * Author: ahorek (Pavel Rosický) * Status: Open * ruby -v: ruby 4.1.0dev (2026-01-31T09:41:30Z master 7ef8c470d2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Loofah sanitization is noticeably slower ``` Ruby: 3.4.8 Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 26.091872 0.000000 26.091872 ( 25.110925) Loofah.scrub_fragment(:prune) 25.913185 0.010392 25.923577 ( 24.948464) Nokogiri HTML parse only 3.852690 0.000000 3.852690 ( 3.705930) Ruby: 4.0.0 & 4.0.1 Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 38.094207 0.041753 38.135960 ( 36.669463) Loofah.scrub_fragment(:prune) 40.168795 0.000045 40.168840 ( 38.561806) Nokogiri HTML parse only 4.012936 0.052024 4.064960 ( 3.913272) Ruby: 4.1.0 (ruby 4.1.0dev (2026-01-31T09:41:30Z master 7ef8c470d2) +PRISM [x86_64-linux]) Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 39.004228 0.000000 39.004228 ( 37.694873) Loofah.scrub_fragment(:prune) 39.043199 0.031284 39.074483 ( 37.182785) Nokogiri HTML parse only 3.889100 0.010427 3.899527 ( 3.741622) ``` Originally reported https://www.redmine.org/issues/43737 ---Files-------------------------------- benchmark.rb (1002 Bytes) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124887] [Ruby Bug#21926] Thread#value on popen3 wait thread hangs in finalizer
by stevecrozz (Stephen Crosby) 10 Mar '26

10 Mar '26

Issue #21926 has been reported by stevecrozz (Stephen Crosby). ---------------------------------------- Bug #21926: Thread#value on popen3 wait thread hangs in finalizer https://bugs.ruby-lang.org/issues/21926 * Author: stevecrozz (Stephen Crosby) * Status: Open * ruby -v: 3.3.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Calling Thread#value on an Open3.popen3 wait thread from a finalizer completes in Ruby 3.2 but hangs in Ruby 3.3+. See repro.rb below. When the Ruby process hangs in these conditions, it no longer responds to signals and it seems to be unable to run any other threads. This affects the schmooze gem (and potentially other code using Open3.popen3 with finalizers), causing test suites to hang intermittently. ``` ruby # repro.rb require 'open3' class ProcessWrapper def initialize @stdin, @stdout, @stderr, @wait_thread = Open3.popen3("cat") ObjectSpace.define_finalizer(self, self.class.make_finalizer(@stdin, @stdout, @stderr, @wait_thread)) end def self.make_finalizer(stdin, stdout, stderr, wait_thread) proc do stdin.close rescue nil stdout.close rescue nil stderr.close rescue nil wait_thread.value # Hangs here in Ruby 3.3+ end end end 100.times { ProcessWrapper.new } GC.stress = true 1000.times { Object.new } puts "done" ``` ## Environment - Linux x86_64 - Tested on Ruby 3.2.7, 3.3.7, 3.4.8 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124970] [Ruby Bug#19017] Net::HTTP may block when attempting to reuse a persistent connection
by ioquatix (Samuel Williams) 10 Mar '26

10 Mar '26

Issue #19017 has been updated by ioquatix (Samuel Williams). I personally thing `eof?` being blocking is extremely confusing. I personally use this shim: https://github.com/socketry/io-stream/blob/main/lib/io/stream/shim/readable… I also mentioned the issue here: https://bugs.ruby-lang.org/issues/20215 @joshc wdyt? ---------------------------------------- Bug #19017: Net::HTTP may block when attempting to reuse a persistent connection https://bugs.ruby-lang.org/issues/19017#change-116660 * Author: joshc (Josh C) * Status: Open * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Ruby's Net::HTTP code performs a blocking `Net::BufferedIO#eof?` check when attempting to reuse a persistent HTTP connection. See https://github.com/ruby/ruby/blob/6b099328af2ae2d04cbfd06fedc36a19cdecd30d/…. The bug is the check can hang for up to the HTTP `read_timeout`, which is 60 seconds by default. The code calls `TCPSocket#wait_readable(0)` to see if the socket is readable before calling the blocking `eof?` method. However, it's possible for the socket to be readable with SSL Handshake records and no Application Data. So the call to `eof?` will process the SSL Handshake records, but hang since no Application Data is available. The issue can be triggered if a TLS 1.3 server sends a `NewSessionTicket` sometime after Application Data is written. The attached client and server code demonstrate the problem. Note it's important that the client and server be on separate hosts otherwise `eof?` will always return immediately. On the server, copy `Server.java` and `certs.p12` into a directory, install JDK 17, compile the server and run it: ``` $ openssl pkcs12 -info -in certs.p12 -noout -passin pass:password MAC: sha1, Iteration 2048 MAC length: 20, salt length: 8 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 $ sudo apt install -y openjdk-17-jdk openjdk-17-jre $ javac Server.java $ java -Djavax.net.debug=ssl,verbose Server Loaded pkcs12 ``` On the client, copy `http.rb` and `ca.pem` into a directory, add the IP address for the server as `pluto` to `/etc/hosts`: ``` $ file ca.pem $ sudo vi /etc/hosts ... 192.168.0.10 pluto ... $ ruby --version ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux] $ openssl version OpenSSL 1.1.1f 31 Mar 2020 ``` Run the client to make the first request: ``` $ ruby http.rb opening connection to pluto:8888... opened starting SSL for pluto:8888... ``` The server will handle request_1 and trigger a new session ticket: ``` javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:23.269 UTC|SSLCipher.java:466|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 Connected to 37532 Handling request_0 ... snip ... javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:25.310 UTC|SSLCipher.java:2024|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:25.335 UTC|SSLCipher.java:1870|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 read body updated session data javax.net.ssl|ALL|10|main|2022-09-22 18:18:25.343 UTC|SSLSocketImpl.java:1564|trigger new session ticket wrote response Handling request_1 ``` The client will hang when trying to reuse the persistent connection: ``` OSSL_DEBUG: SSL SESSION new callback added [ossl_ssl.c:963] SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384 <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] ``` Pressing Ctrl-C shows the backtrace: ``` ^CTraceback (most recent call last): 11: from http.rb:10:in `<main>' 10: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:933:in `start' 9: from http.rb:17:in `block in <main>' 8: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1294:in `post' 7: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1506:in `send_entity' 6: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1492:in `request' 5: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1518:in `transport_request' 4: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1573:in `begin_transport' 3: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/protocol.rb:134:in `eof?' 2: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:300:in `eof?' 1: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:57:in `fill_rbuff' /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:57:in `sysread': Interrupt ``` I get the same behavior with latest ruby too: ``` $ ruby --version ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] ``` Changing Net::HTTP to the following: ``` elsif @socket.io.read_nonblock(0, exception: false).nil? ``` Resolves the issue: ``` $ ruby http.rb opening connection to pluto:8888... opened starting SSL for pluto:8888... OSSL_DEBUG: SSL SESSION new callback added [ossl_ssl.c:963] SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384 <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive ``` However, based on https://github.com/ruby/ruby/pull/1089#issuecomment-159878003 that change may not be correct. Or it could be that Ruby on Windows doesn't have this issue anymore. ---Files-------------------------------- Server.java (3.75 KB) http.rb (423 Bytes) ca.pem (8.43 KB) certs.p12 (2.24 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124804] [Ruby Bug#21876] Addrinfo.getaddrinfo(AF_UNSPEC) deadlocks after fork on macOS for IPv4-only hosts
by nbeyer＠gmail.com (Nathan Beyer) 09 Mar '26

09 Mar '26

Issue #21876 has been reported by nbeyer(a)gmail.com (Nathan Beyer). ---------------------------------------- Bug #21876: Addrinfo.getaddrinfo(AF_UNSPEC) deadlocks after fork on macOS for IPv4-only hosts https://bugs.ruby-lang.org/issues/21876 * Author: nbeyer(a)gmail.com (Nathan Beyer) * Status: Open * ruby -v: ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On macOS, `Addrinfo.getaddrinfo(host, service, Socket::AF_UNSPEC, Socket::SOCK_STREAM)` can deadlock in forked child processes when the host has no AAAA (IPv6) DNS records and the parent process previously resolved the same host. This happened to me when using an HTTP library to acquire an OAuth access token in a Rails initializer and then the process was forked, then a separate call was made to the same host in the forked process. ## Environment - macOS (tested on arm64-darwin24 and arm64-darwin25, Apple Silicon) - Ruby 3.4.7, 3.4.8 - The issue is probabilistic — frequency varies by environment but is highly reproducible under sustained DNS activity ## Reproduction Minimal example: ```ruby require "socket" require "timeout" # Parent resolves an IPv4-only host (no AAAA records) Addrinfo.getaddrinfo("httpbin.org", "https", Socket::AF_UNSPEC, Socket::SOCK_STREAM) pid = fork do begin Timeout.timeout(5) do Addrinfo.getaddrinfo("httpbin.org", "https", Socket::AF_UNSPEC, Socket::SOCK_STREAM) end puts "Child: OK" rescue Timeout::Error puts "Child: DEADLOCK — getaddrinfo hung for 5s" end end Process.waitpid(pid) ``` The issue is probabilistic — a single invocation may or may not deadlock. The attached script runs 50 trials each for several variants to demonstrate the pattern. Deadlock may not happen on the first run, but if you run it several times, you should see at least a single deadlock in Test 2, if not deadlock of all results in Test 1 and Test 2. See attachment - ruby_getaddrinfo_fork_bug.rb Typical output: ``` Test 1 (single IPv4-only host): 20/20 deadlocked Test 2 (multi-host warmup): 20/20 deadlocked Test 3 (dual-stack host control): 0/20 deadlocked Test 4 (AF_INET workaround): 0/20 deadlocked ``` ## Context The deadlock occurs when ALL of these conditions hold: 1. **macOS** (not observed on Linux) 2. Parent called `getaddrinfo(host, AF_UNSPEC)` for a host with **no AAAA (IPv6) records** 3. Child calls `getaddrinfo` for the **same host** with `AF_UNSPEC` **Not affected:** - Hosts **with** AAAA records (dual-stack) — e.g., `www.google.com`, `rubygems.org` - Using `Socket::AF_INET` instead of `Socket::AF_UNSPEC` - Hosts the parent never resolved | Host | AAAA records | Child deadlocks? | |------|-------------|-----------------| | httpbin.org | None | **Yes** | | www.github.com | None | **Yes** | | api.github.com | None | **Yes** | | stackoverflow.com | None | **Yes** | | www.google.com | Yes | No | | rubygems.org | Yes | No | | example.com | Yes | No | | www.cloudflare.com | Yes | No | ## Potential Root Cause As I understand it, on macOS, `getaddrinfo` communicates with the `mDNSResponder` system daemon via Mach IPC ports. When `getaddrinfo(AF_UNSPEC)` queries a host with no AAAA records, the negative AAAA result appears to be cached via Mach port state. After `fork()`, the child process inherits the address space (including references to this cached state) but does **not** inherit the Mach port connections to `mDNSResponder`. When the child calls `getaddrinfo` for the same host, it encounters the stale cache entry and deadlocks trying to communicate over the invalidated Mach port. Hosts with positive AAAA results are not affected, presumably because their cache entries do not require re-contacting `mDNSResponder` in the same code path. ## Feature #20590 Ruby 3.4's fork safety improvements (Feature #20590) added a read-write lock around `getaddrinfo` to prevent `fork()` while a `getaddrinfo` call is actively running. However, this does not address the issue reported here — the problem is not about forking *during* a `getaddrinfo` call, but about stale mDNSResponder Mach port state that is inherited by the child process *after* `getaddrinfo` has completed in the parent. ---Files-------------------------------- ruby_getaddrinfo_fork_bug.rb (5.36 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124864] [Ruby Misc#21922] Permissions for committers for default/bundled/unbundled gems repositories
by Eregon (Benoit Daloze) 09 Mar '26

09 Mar '26

Issue #21922 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21922: Permissions for committers for default/bundled/unbundled gems repositories https://bugs.ruby-lang.org/issues/21922 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I noticed recently that the team `ruby-committers` on GitHub no longer has write access to at least: * https://github.com/ruby/benchmark * https://github.com/ruby/cmath * https://github.com/ruby/curses * https://github.com/ruby/dbm * https://github.com/ruby/e2mmap * https://github.com/ruby/gdbm * https://github.com/ruby/getoptlong * https://github.com/ruby/iconv * https://github.com/ruby/mathn * https://github.com/ruby/mutex_m * https://github.com/ruby/net-ftp * https://github.com/ruby/net-pop * https://github.com/ruby/net-telnet * https://github.com/ruby/observer * https://github.com/ruby/pathname (marked as maintained by @akr but they don't reply on GitHub, there is also an unclear relation with core Pathname [which still hasn't been resolved](https://github.com/ruby/pathname/issues/66) and is causing warnings for months) * https://github.com/ruby/prime * https://github.com/ruby/pstore * https://github.com/ruby/readline * https://github.com/ruby/readline-ext * https://github.com/ruby/ruby2_keywords * https://github.com/ruby/scanf * https://github.com/ruby/sdbm * https://github.com/ruby/set * https://github.com/ruby/shell * https://github.com/ruby/syck * https://github.com/ruby/sync * https://github.com/ruby/thwait * https://github.com/ruby/tk * https://github.com/ruby/tracer * https://github.com/ruby/webrick * https://github.com/ruby/win32api * https://github.com/ruby/xmlrpc This list is from a couple cases I noticed myself + [all repos](https://github.com/orgs/ruby/repositories?q=mirror%3Afalse+fork%3Afa… - [those committers have access](https://github.com/orgs/ruby/teams/ruby-committers/repositories) - [repos with known maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md)) I filtered manually so there could be some mistake(s), though I tried to check carefully. I am certain CRuby committers had access to some of these repositories (e.g. I merged PRs there), but not sure about all, some might already not have had write access for CRuby committers. It seems only the 4 owners of the Ruby GitHub organization have write access to these repositories. What motivated these changes? I believe it is valuable that all CRuby committers can merge to default/bundled/unbundled gems repositories *without active maintainers*, as it was before. There is [this list](https://github.com/ruby/ruby/blob/master/doc/maintainers.md) to define maintainers, though it's a little bit outdated and inaccurate. It's fine enough for this issue though. (A better definition IMO for active maintainers would be maintainers would actually respond to PRs and issues on GitHub to these repositories otherwise they are effectively not maintaining that repository, at least from an external perspective.) IOW it seems unreasonable to always have to ask one of the 4 owners of the Ruby GitHub organization to merge a PR to such repositories, as it would be a significant overhead for committers and for owners, and it would delay merging PRs significantly. I'm thinking for example to * documentation PRs ([many for pathname](https://github.com/ruby/pathname/pulls)) which really shouldn't need an owner to merge * PRs to improve/fix the CI ([example](https://github.com/ruby/readline-ext/pull/29)) * PRs fixing compatibility with recent changes in ruby's master branch * etc. Yet another way to see this is many default/bundled/unbundled gems do not have active maintainers. AFAIK so far in such cases then all CRuby committers could help, but this seems no longer the case. (FWIW I saw there a `default-gems-contributor` team with 3 people, which explains why they can merge PRs to some repositories that ruby committers can't for example.) -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124956] [Ruby Misc#21949] timeout gem maintainer
by Eregon (Benoit Daloze) 09 Mar '26

09 Mar '26

Issue #21949 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21949: timeout gem maintainer https://bugs.ruby-lang.org/issues/21949 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- The timeout has currently [no official active maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md). I would like to propose myself as maintainer of the [timeout](https://github.com/ruby/timeout) gem. I basically rewrote the implementation in https://github.com/ruby/timeout/pull/15 and acted as a maintainer since then by reviewing PRs and replying to issues. I also recently solved all open issues except https://github.com/ruby/timeout/issues/52 (where I have a draft PR to try to solve it and need more time to validate the fix). Among other [recent active contributors](https://github.com/ruby/timeout/graphs/contributors) I see @nobu, would you like to be maintainer of timeout as well? -- https://bugs.ruby-lang.org/

2 8

[ruby-core:124955] [Ruby Misc#21948] benchmark gem maintainer
by Eregon (Benoit Daloze) 09 Mar '26

09 Mar '26

Issue #21948 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21948: benchmark gem maintainer https://bugs.ruby-lang.org/issues/21948 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to propose myself as maintainer of [benchmark](https://github.com/ruby/benchmark). I always had an interest about the `benchmark` stdlib and did significant contributions to it, notably [979ec8d](https://github.com/ruby/ruby/commit/979ec8df5daf6db314b2f17e53b53d…. @matz approved it [here](https://github.com/ruby/ruby/pull/15424#issuecomment-3640875676), so this issue is mostly for awareness. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:123992] [Ruby Bug#21760] Ruby::Box: a couple of require-related problems
by zverok (Victor Shepelev) 09 Mar '26

09 Mar '26

Issue #21760 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21760: Ruby::Box: a couple of require-related problems https://bugs.ruby-lang.org/issues/21760 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: 4.0.0dev (2025-12-03T05:16:03Z master 4762f429f4) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am not sure whether all the problems have the same nature, but putting them together for now. **1. Enabling box breaks `gem`+`require`** Minimal reproducible example: `test.rb`: ```ruby gem 'faraday', '= 2.14.0' require 'faraday' p Faraday::VERSION ``` (Note that there is no explicit use of `Ruby::Box`) Running it with and without `RUBY_BOX`: ```sh $ ruby test.rb "2.14.0" $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' ``` (sic, the error is printed twice) **2. requiring the same gem from `Box`-loaded file and the main file** `box.rb`: ```ruby require 'faraday' p "In a box: #{Faraday::VERSION}" ``` `main.rb` ```ruby b = Ruby::Box.new b.load('box.rb') require 'faraday' ``` ```sh $ RUBY_BOX=1 ruby main.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. "In a box: 2.14.0" main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' ``` **3. `Box#require` seem to not be aware of gems** In the example above, we see that Box-loaded file can require a gem. This also works: ```ruby b = Ruby::Box.new b.eval(<<~RUBY) require "faraday" p Faraday::VERSION RUBY ``` (prints "2.14.0" as expected) But this doesn't: ```ruby b = Ruby::Box.new b.require('faraday') ``` ```sh $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. test.rb:3:in 'Ruby::Box#require': cannot load such file -- faraday (LoadError) from test.rb:3:in '<main>' ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124950] [Ruby Bug#21947] `Timeout.timeout` doesn't use `Timeout::ExitException` when Fiber scheduler is in use.
by ioquatix (Samuel Williams) 09 Mar '26

09 Mar '26

Issue #21947 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21947: `Timeout.timeout` doesn't use `Timeout::ExitException` when Fiber scheduler is in use. https://bugs.ruby-lang.org/issues/21947 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The following example executes successfully after 7 seconds instead of timing out after 2. ```ruby require 'async' require 'net/http' start = Time.now Sync do Timeout.timeout 2 do Net::HTTP.get(URI 'https://httpbin.org/delay/5') puts "...request finished, no timeout though; in #{Time.now - start}s" end end puts "Duration: #{Time.now - start}s" # => ...request finished, no timeout though; in 7.7007s # Duration: 7.700962s ``` There are two issues: - `Net::HTTP` rescues `Timeout::Error` and retries. This causes 2s (timeout -> retry) + 5s execution time. - `Timeout.timeout` uses `Timeout::ExitException` when no exception is specified, but the Fiber scheduler code path was not updated. See <https://github.com/socketry/async/issues/448> for more discussion. -- https://bugs.ruby-lang.org/

1 2