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

[ruby-core:120897] [Ruby master Bug#21119] Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly.
by genya0407 (Yusuke Sangenya) 05 Sep '26

05 Sep '26

Issue #21119 has been reported by genya0407 (Yusuke Sangenya). ---------------------------------------- Bug #21119: Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly. https://bugs.ruby-lang.org/issues/21119 * Author: genya0407 (Yusuke Sangenya) * Status: Open * ruby -v: ruby 3.5.0dev (2025-02-06T14:10:34Z master adbf9c5b36) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Executing the following code in Ruby 3.4.1 takes a very long time, especially when there are many files $100~$ in the current directory. This delay does not occur in Ruby 3.3.6. ## Reproducible script ```ruby # hoge.rb # Launch a thread to execute CPU-heavy task Thread.new do loop do arr = [] 100.times do arr << rand(1...100) end end end # Execute a program containing `Dir.glob` in the main thread. 10.times do Dir.glob('*') puts "aaaa" end ``` ## Execution Results Executiong the above code in Ruby 3.4.1 takes **119.43s**. ```shell $ ruby -v ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] $ time ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ruby hoge.rb 119.43s user 0.30s system 99% cpu 1:59.89 total ``` Executing it in Ruby master also takes **118.87s**. ```shell $ ~/opt-ruby/bin/ruby -v ruby 3.5.0dev (2025-02-06T14:10:34Z master adbf9c5b36) +PRISM [arm64-darwin24] $ time ~/opt-ruby/bin/ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ~/opt-ruby/bin/ruby hoge.rb 118.87s user 0.46s system 99% cpu 2:00.45 total ``` Executing it in Ruby 3.3.6 takes only **2.22s**. ```shell $ ruby -v ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [arm64-darwin24] $ time ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ruby hoge.rb 2.22s user 0.03s system 98% cpu 2.286 total ``` So, there are roughly **50x** delays. ## Possible Cause From Ruby 3.4.0, `Dir.glob` releases the GVL frequently. * https://bugs.ruby-lang.org/issues/20587 * https://github.com/ruby/ruby/pull/11147 Due to this change, when a CPU-heavy thread releases the GVL, `Dir.glob` also releases the GVL immediately. As a result, `Dir.glob` gets significantly delayed because it has to continuously regain the GVL causing a major slowdown in execution. ## Note about Execution Results I measured the execution results under a stress condition, with 100 files in the current directory. If there are fewer files, the slowdown may be less pronounced. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:126568] [Ruby Bug#19017] Net::HTTP may block when attempting to reuse a persistent connection
by joshc (Josh C) 04 Sep '26

04 Sep '26

Issue #19017 has been updated by joshc (Josh C). I think we're all in agreement that mixing non-blocking read with blocking eof? is a recipe for disaster. I would welcome a non-blocking eof? check in IO that Net::HTTP can just call. Hopefully https://bugs.ruby-lang.org/issues/20215 can be implemented and merged. PR https://github.com/ruby/net-http/pull/232 looks good to me as an immediate solution. I know it's not ideal for Net::HTTP to reach into IO, but I don't know if/when #20215 will be implemented. I just ran into this issue again and found it happens trivially with Jetty 10/11, because it opportunistically sends [NewSessionTicket on an idle connection along with an empty message](https://github.com/jetty/jetty.project/blob/1e95549f1aa70c1760de8f…. The [`NEED_WRAP`](https://github.com/openjdk/jdk/blob/f1c7c3e9bc0c8794dbf16b4fdc31464d5abe473b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java#L139-L146) comes from the SSLEngine indicating "I have data to send" In Jetty 12, the problem doesn't seem to occur. I believe this is because they rewrote the core IO, and NewSessionTickets are always sent on the next active response, never on an idle socket. ---------------------------------------- Bug #19017: Net::HTTP may block when attempting to reuse a persistent connection https://bugs.ruby-lang.org/issues/19017#change-118777 * 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:126558] [Ruby Bug#22287] Prism aborts in pm_newline_list_append when requiring a file after fork
by Morred (Laura Eck) 04 Sep '26

04 Sep '26

Issue #22287 has been reported by Morred (Laura Eck). ---------------------------------------- Bug #22287: Prism aborts in pm_newline_list_append when requiring a file after fork https://bugs.ruby-lang.org/issues/22287 * Author: Morred (Laura Eck) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby crashed on me while I was running our precommit hooks, during the Rubocop step, with the following output: ``` Assertion failed: (list->size == 0 || newline_offset > list->offsets[list->size - 1]), function pm_newline_list_append, file pm_newline_list.c, line 51. /Users/laura.eck/Projects/jeancaisse/lib/constants/feature_flags.rb: [BUG] Aborted at 0x000000018415c5e8 ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0055 p:---- s:0300 e:000299 l:y b:---- DUMMY [FINISH] c:0054 p:---- s:0297 e:000296 l:y b:0001 CFUNC :require_relative c:0053 p:0005 s:0292 e:000291 l:y b:0001 TOP /Users/laura.eck/Projects/<redacted>/lib/cops/<redacted>/dx/feature_flag_setup.rb:3 [FINISH] c:0052 p:---- s:0289 e:000288 l:y b:0001 CFUNC :require c:0051 p:0033 s:0284 e:000283 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60 c:0050 p:0023 s:0278 e:000277 l:n b:---- BLOCK /Users/laura.eck/Projects/<redacted>/lib/cops.rb:46 [FINISH] c:0049 p:0027 s:0274 e:000273 l:y b:0001 METHOD <internal:array>:228 c:0048 p:0096 s:0268 e:000267 l:y b:0001 TOP /Users/laura.eck/Projects/<redacted>/lib/cops.rb:43 [FINISH] c:0047 p:---- s:0265 e:000264 l:y b:0001 CFUNC :require c:0046 p:0033 s:0260 e:000259 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60 c:0045 p:0006 s:0254 e:000253 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:35 c:0044 p:0020 s:0248 e:000247 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:21 c:0043 p:0083 s:0241 e:000240 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:32 [FINISH] c:0042 p:0027 s:0236 e:000235 l:y b:0001 METHOD <internal:array>:228 c:0041 p:0008 s:0230 e:000229 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:21 c:0040 p:0003 s:0226 e:000225 l:y b:0001 METHOD <internal:kernel>:91 c:0039 p:0017 s:0222 e:000221 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:20 c:0038 p:0060 s:0215 e:000214 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:63 c:0037 p:0022 s:0202 e:000201 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:128 c:0036 p:0089 s:0194 e:000190 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:73 c:0035 p:0007 s:0185 e:000184 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:52 c:0034 p:0010 s:0181 e:000180 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:92 c:0033 p:0015 s:0178 e:000177 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cache_config.rb:9 c:0032 p:0023 s:0173 e:000172 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:91 c:0031 p:0050 s:0166 e:000164 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:172 c:0030 p:0018 s:0160 e:000159 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:49 c:0029 p:0011 s:0157 e:000156 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:89 c:0028 p:0069 s:0147 e:000146 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:45 c:0027 p:0035 s:0138 e:000137 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/exec.rb:22 c:0026 p:0004 s:0133 e:000132 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:24 [FINISH] c:0025 p:---- s:0130 e:000129 l:y b:0001 CFUNC :chdir c:0024 p:0012 s:0125 e:000124 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:23 c:0023 p:0007 s:0121 e:000120 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:33 c:0022 p:0059 s:0118 e:000117 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/helper.rb:26 c:0021 p:0056 s:0106 e:000105 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:28 c:0020 p:0019 s:0100 e:000099 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:93 c:0019 p:0014 s:0094 e:000093 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:68 c:0018 p:0012 s:0091 e:000090 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:131 c:0017 p:0005 s:0087 e:000086 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:67 c:0016 p:0052 s:0083 e:000082 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:56 [FINISH] c:0015 p:---- s:0080 e:000079 l:y b:0001 CFUNC :fork c:0014 p:0008 s:0076 e:000075 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:47 c:0013 p:0042 s:0071 e:000070 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:39 c:0012 p:0063 s:0063 e:000062 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:4 c:0011 p:0021 s:0057 e:000056 l:n b:---- BLOCK /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:120 [FINISH] c:0010 p:---- s:0052 e:000051 l:y b:0001 CFUNC :open c:0009 p:0010 s:0046 e:000045 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:117 c:0008 p:0033 s:0042 e:000041 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:2 c:0007 p:0085 s:0038 e:000037 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:93 c:0006 p:0156 s:0031 e:000030 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:83 c:0005 p:0041 s:0023 e:000022 l:y b:0001 METHOD /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:49 c:0004 p:0043 s:0018 e:000017 l:y b:0001 TOP /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/exe/rubocop:8 [FINISH] c:0003 p:---- s:0013 e:000012 l:y b:0001 CFUNC :load c:0002 p:0111 s:0008 E:0019d0 l:n b:---- EVAL bin/rubocop:52 [FINISH] c:0001 p:0000 s:0003 E:002250 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bin/rubocop:52:in '<main>' bin/rubocop:52:in 'load' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/exe/rubocop:8:in '<top (required)>' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:49:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:83:in 'process_arguments' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cli.rb:93:in 'run_command' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:29:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:117:in 'acquire_lock' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:117:in 'open' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:120:in 'block in acquire_lock' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/client_command/start.rb:42:in 'block in run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:39:in 'start' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:47:in 'detach_server' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:47:in 'fork' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:56:in 'block in detach_server' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:67:in 'process_input' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/cache.rb:131:in 'write_pid_file' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:68:in 'block in process_input' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/core.rb:93:in 'read_socket' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:28:in 'read!' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/helper.rb:26:in 'redirect' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/socket_reader.rb:33:in 'block in read!' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:23:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:23:in 'chdir' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/base.rb:24:in 'block in run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/server/server_command/exec.rb:22:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:45:in 'run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:89:in 'profile_if_needed' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:49:in 'block in run' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cli.rb:172:in 'act_on_options' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:91:in 'cache_root' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/cache_config.rb:9:in 'root_dir' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/result_cache.rb:92:in 'block in cache_root' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:52:in 'for_pwd' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_store.rb:73:in 'for_dir' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:128:in 'configuration_from_file' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader.rb:63:in 'load_file' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:20:in 'resolve_requires' <internal:kernel>:91:in 'tap' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:21:in 'block in resolve_requires' <internal:array>:228:in 'each' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/config_loader_resolver.rb:32:in 'block (2 levels) in resolve_requires' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:21:in 'load' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/gems/4.0.0/gems/rubocop-1.87.0/lib/rubocop/feature_loader.rb:35:in 'load' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /Users/laura.eck/Projects/jeancaisse/lib/cops.rb:43:in '<top (required)>' <internal:array>:228:in 'each' /Users/laura.eck/Projects/<redacted>/lib/cops.rb:46:in 'block in <top (required)>' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' /Users/laura.eck/Projects/<redacted>/lib/cops/<redacted>/dx/feature_flag_setup.rb:3:in '<top (required)>' /Users/laura.eck/Projects/<redacted>/lib/cops/<redacted>/dx/feature_flag_setup.rb:3:in 'require_relative' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x000000000000002e x6: 0x0000000000000000 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x0000000000000203 x21: 0x00000001f0bd6260 x22: 0x0000000000000001 x23: 0x0000000101f471a1 x24: 0x00000001ee10a000 x25: 0x0000000000000001 x26: 0x000000016eed28b0 x27: 0x0000000101f6d3f8 x28: 0x0000000000000001 lr: 0x00000001841978d8 fp: 0x000000016eed23f0 sp: 0x000000016eed23d0 -- C level backtrace information ------------------------------------------- /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(rb_vm_bugreport+0xbc8) [0x101ce9fc4] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(rb_bug_for_fatal_signal+0x10c) [0x101b066a0] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(sigabrt+0x90) [0x101c3c228] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x1841a1744] /usr/lib/system/libsystem_pthread.dylib(pthread_kill+0x128) [0x1841978d8] /usr/lib/system/libsystem_c.dylib(abort+0x94) [0x18409d978] [0x18409cbd4] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_newline_list_append.cold.2+0x0) [0x101f163b8] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_newline_list_append+0x0) [0x101d32b90] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_parser_lex+0xe1c) [0x101d36850] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_parse+0x88) [0x101d34110] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_pm_parse_file+0xb0) [0x101a9184c] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_load_iseq_eval+0xa4) [0x101b7b17c] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_require_internal+0x31c) [0x101b79314] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_require_string_internal+0x60) [0x101b78890] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_vm_call_cfunc_with_frame_+0xf0) [0x101cd97f0] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_vm_exec_core+0x2378) [0x101cbbd08] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_vm_exec+0x268) [0x101cb7d2c] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_load_iseq_eval+0x230) [0x101b7b308] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_require_internal+0x31c) [0x101b79314] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_require_string_internal+0x60) [0x101b78890] /Users/laura.eck/.asdf/installs/ruby/4.0.6/lib/libruby.4.0.dylib(_rb_f_require+0x44) [0x101b78758] -- Other runtime information ----------------------------------------------- * Loaded script: rubocop --server /Users/laura.eck/Projects/<redacted> [I'm omitting the rest of the 3500 line output] ``` Crash report file is attached to this ticket. Please let me know if I can help out with any more information. ---Files-------------------------------- ruby-2026-09-03-133824.ips (20.8 KB) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126559] [Ruby Bug#22288] doc: Pathname: rmtree is claimed to return 0, it actually returns self
by akim2 (Akim Demaille) 03 Sep '26

03 Sep '26

Issue #22288 has been reported by akim2 (Akim Demaille). ---------------------------------------- Bug #22288: doc: Pathname: rmtree is claimed to return 0, it actually returns self https://bugs.ruby-lang.org/issues/22288 * Author: akim2 (Akim Demaille) * Status: Open * ruby -v: 4.0 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

1 0

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

02 Sep '26

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

1 1

[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) 02 Sep '26

02 Sep '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/

1 0

[ruby-core:126554] [Action Required] :️ Suspicious Activities Detected on ruby-core@ruby-lang.org
by Postmaster 01 Sep '26

01 Sep '26

1 0