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

[ruby-core:126222] [Ruby Bug#22223] Socket.tcp with connect_timeout returns a phantom "connected" socket for a refused connection on macOS 27 (kernel answers EISCONN on connect retry; SO_ERROR never consulted)
by tdehnke (Tony Dehnke) 09 Aug '26

09 Aug '26

Issue #22223 has been reported by tdehnke (Tony Dehnke). ---------------------------------------- Bug #22223: Socket.tcp with connect_timeout returns a phantom "connected" socket for a refused connection on macOS 27 (kernel answers EISCONN on connect retry; SO_ERROR never consulted) https://bugs.ruby-lang.org/issues/22223 * Author: tdehnke (Tony Dehnke) * Status: Open * ruby -v: ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On macOS 27.0 (beta, build 26A5388g, arm64 — M5), `Socket.tcp(host, port, connect_timeout: X)` returns a socket object instead of raising `Errno::ECONNREFUSED` when nothing is listening on the port. The returned socket is not usable (first `write` raises `Errno::EPIPE`). The blocking paths (`connect_timeout: nil`, `TCPSocket.new`) raise `Errno::ECONNREFUSED` correctly. ⚠️ Note: this is a macOS **beta** build; the kernel behavior may change before release. Reporting anyway because Ruby's connect idiom is not robust against it, and the failure is silent (phantom success, not an error). ## Repro (no listener on port 3999) ```ruby require "socket" Socket.tcp("127.0.0.1", 3999, connect_timeout: 1) # => #<Socket ...> (expected: Errno::ECONNREFUSED) Socket.tcp("127.0.0.1", 3999, connect_timeout: 1, fast_fallback: false) # => #<Socket ...> (same — not Happy-Eyeballs-specific) Socket.tcp("127.0.0.1", 3999, connect_timeout: nil) # blocking path # => Errno::ECONNREFUSED (correct) TCPSocket.new("127.0.0.1", 3999) # => Errno::ECONNREFUSED (correct) s = Socket.tcp("127.0.0.1", 3999, connect_timeout: 1) s.write("x") # => Errno::EPIPE — the "connected" socket was never connected ``` Reproduced identically on ruby 3.4.5 (arm64-darwin27) and ruby 3.4.10 (arm64-darwin27). Other tools on the same machine (curl, a blocking C connect) report Connection refused correctly and instantly. ## Root cause observed The classic nonblocking idiom — `connect_nonblock` → wait writable → retry `connect_nonblock`, treating `Errno::EISCONN` as success (as recommended in Ruby's own `connect_nonblock` documentation, and as used by `Socket.tcp`'s connect_timeout path) — is broken by a Darwin 27 kernel behavior change. C-level demonstration on a refused nonblocking connect: ``` first connect: r=-1 errno=36 (Operation now in progress) poll: r=1 revents=0x10 # POLLHUP — yet the fd is reported "ready" retry connect: r=-1 errno=56 (Socket is already connected) # EISCONN, on a REFUSED socket SO_ERROR: 61 (Connection refused) # the truth is still available here ``` So the kernel answers the retry-`connect(2)` with `EISCONN` instead of `ECONNREFUSED`, and Ruby's idiom takes that as "connected". `getsockopt(SO_ERROR)` still reports `ECONNREFUSED` — checking it after writability (before/instead of trusting the connect-retry result) detects the failure correctly. Ruby-level equivalent: ```ruby sock = Socket.new(:INET, :STREAM) addr = Socket.sockaddr_in(3999, "127.0.0.1") begin sock.connect_nonblock(addr) rescue IO::WaitWritable sock.wait_writable(2) # returns "writable" begin sock.connect_nonblock(addr) # raises Errno::EISCONN (!) rescue Errno::EISCONN sock.getsockopt(Socket::SOL_SOCKET, Socket::SO_ERROR).int # => 61 ECONNREFUSED end end ``` ## Impact Any code probing "is something listening?" via `Socket.tcp` with a `connect_timeout` silently gets a false positive on this platform. Found in the wild: shakapacker's `Shakapacker::DevServer#running?` (probe with `connect_timeout: 0.1`) reported a webpack dev server that wasn't there, so its Rails middleware proxied every asset request into a dead port — every page 502s with no error pointing anywhere near the cause. ## Suggested direction After waiting for writability in the connect_timeout / HEv2 paths (and possibly in the documented `connect_nonblock` idiom), consult `getsockopt(SO_ERROR)` rather than relying on the retry-`connect` returning `EISCONN` — SO_ERROR carries the correct `ECONNREFUSED` even when the kernel misanswers the retry. (Also plausibly worth an Apple Feedback report; the poll `revents=POLLHUP`-as-ready + `EISCONN`-on-refused combination looks like an OS regression.) ## Environment - macOS 27.0 (beta), build 26A5388g, Apple Silicon (M5), Darwin 27 - ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin27] — also ruby 3.4.10 [arm64-darwin27] - Possibly related (different symptom, same neighborhood): Bug #21104 (Net::HTTP failures on macOS ≥ 3.4, hardware-dependent, RUBY_TCP_NO_FAST_FALLBACK workaround). Unlike #21104, this repro is NOT affected by `fast_fallback: false`. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126344] [Ruby Bug#11438] native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32
by nagachika (Tomoyuki Chikanaga) 09 Aug '26

09 Aug '26

Issue #11438 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED to 3.3: WONTFIX, 3.4: DONE, 4.0: REQUIRED ruby_3_4 commit:44145cf4dc64fa4cebbec10d2ec3454fbfd65559 merged revision(s) commit:e585c9449965a6837374e0c5436cf4be731802df. ---------------------------------------- Bug #11438: native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32 https://bugs.ruby-lang.org/issues/11438#change-118461 * Author: rickerliang (l ly) * Status: Closed * Assignee: windows * ruby -v: 2.2.2 * Backport: 3.3: WONTFIX, 3.4: DONE, 4.0: REQUIRED ---------------------------------------- In function native_thread_init_stack() use VirtualQuery to get thread's stack start address.But some situation(ruby embbed in other application and initial it on the fly),native_thread_init_stack() will be called at low stack address and VirtualQuery return memory info BaseAddress + RegionSize < thread stack base(teb.StackBase). In this situation,subsequently call stack_check() at high stack address will cause stack_overflow exception,because esp > machine.stack_start: (teb.StackLimit < machine.stack_start < esp < teb.StackBase) but actually it is not stack overflow at this time. Use teb.StackBase instead of VirtualQuery get thread stack base is a more reliable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 09 Aug '26

09 Aug '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126098] [Ruby Bug#22198] win32: heap overflow in Kernel#system
by mame (Yusuke Endoh) 09 Aug '26

09 Aug '26

Issue #22198 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22198: win32: heap overflow in Kernel#system https://bugs.ruby-lang.org/issues/22198 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: windows * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `system('foo.exe %A')` looks past `%A` for a closing `%`, reading past the end of the string. It does not reproduce normally, but with page heap enabled it faults: ``` PS C:\> gflags /p /enable ruby.exe /full PS C:\> ruby -e "system('x' * 1024 + '.exe %A')" -e:1: [BUG] Segmentation fault ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 l:y b:0001 CFUNC :system c:0002 p:0013 s:0006 e:000005 l:n b:---- EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:001620 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'system' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007ffbd55000e4] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007ffbd274c11f] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_vm_bugreport+0x237) [0x00007ffb37262227] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_bug_for_fatal_signal+0x9b) [0x00007ffb37000beb] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_shape_free_all+0xfb5) [0x00007ffb37191985] C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007ffbd2fff2e4] [0x00007ff765e81080] C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007ffbd550479f] *snip* ``` PR: https://github.com/ruby/ruby/pull/17929 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126049] [Ruby Bug#22191] `Signal.trap(:EXIT)` exception only shown if `at_exit` also raises
by Earlopain (Earlopain _) 09 Aug '26

09 Aug '26

Issue #22191 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22191: `Signal.trap(:EXIT)` exception only shown if `at_exit` also raises https://bugs.ruby-lang.org/issues/22191 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-29T14:34:40Z master 7a07a54298) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb Signal.trap(:EXIT, proc { raise "foo" }) # No output ``` ```rb Signal.trap(:EXIT, proc { raise "foo" }) at_exit { raise "bar" } # test.rb:2:in 'block in <main>': bar (RuntimeError) # test.rb:1:in 'block in <main>': foo (RuntimeError) ``` A bit weird -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125997] [Ruby Bug#22189] `Enumerator::Lazy#to_enum` does not accept method names as strings
by nobu (Nobuyoshi Nakada) 09 Aug '26

09 Aug '26

Issue #22189 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22189: `Enumerator::Lazy#to_enum` does not accept method names as strings https://bugs.ruby-lang.org/issues/22189 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `Kernel#to_enum` accepts a `String` as well as a `Symbol`. ```ruby [1,2,3].to_enum(:map).to_a #=> [1, 2, 3] [1,2,3].to_enum("map").to_a #=> [1, 2, 3] [1,2,3].lazy.to_enum(:map).to_a #=> [1, 2, 3] [1,2,3].lazy.to_enum("map").to_a #=> [] ``` Related to [Bug #7877]. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125864] [Ruby Bug#22133] Ruby's default SIGINT handling ignores `Thread.handle_interrupt` masking.
by ioquatix (Samuel Williams) 09 Aug '26

09 Aug '26

Issue #22133 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22133: Ruby's default SIGINT handling ignores `Thread.handle_interrupt` masking. https://bugs.ruby-lang.org/issues/22133 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Ruby's default SIGINT handling currently bypasses `Thread.handle_interrupt` masking. When a process receives SIGINT with the default Ruby handler installed, CRuby calls `rb_interrupt()` directly. That can raise `Interrupt` immediately inside code wrapped by `Thread.handle_interrupt(SignalException => :never)`, including while blocked in operations like `Thread::Queue#pop`. This is inconsistent with other asynchronous exception delivery paths, such as `Thread#raise`, and with other default signal exceptions such as SIGTERM. Those paths enqueue a pending interrupt on the target thread, allowing `Thread.handle_interrupt` to defer delivery until the configured point. ## Background This was discovered while working on `Async`/`Async::Container` signal handling. Async relies on `Thread.handle_interrupt` and scheduler-level interruption boundaries to keep signal delivery deterministic. The current default SIGINT path means a Ctrl-C can escape a masked section and interrupt internal synchronization code, which can break graceful shutdown behavior. A minimal reproduction is: ```ruby waiting = Thread::Queue.new release = Thread::Queue.new inner = false Thread.new do waiting.pop Process.kill(:INT, Process.pid) release.push(true) end begin Thread.handle_interrupt(SignalException => :never) do begin waiting.push(true) release.pop rescue Interrupt inner = true raise end end rescue Interrupt puts "outer" end puts inner ``` Expected output: ```text outer false ``` Current affected behavior can produce `inner == true`, meaning the `Interrupt` was delivered inside the masked region. ## Proposed fix Route default SIGINT through the same pending-interrupt mechanism as other default signal exceptions, while preserving the traditional exception class and no-message `Interrupt` object. Concretely, the PR replaces the direct `rb_interrupt()` default SIGINT path with a helper that enqueues an `Interrupt` on the main thread and wakes that thread. This makes default SIGINT respect `Thread.handle_interrupt(SignalException => :never)` in the same way as default SIGTERM/SignalException and `Thread#raise`. ## Pull request PR: https://github.com/ruby/ruby/pull/17533 The PR includes: 1. A failing regression test for default SIGINT with `Thread.handle_interrupt`. 2. The implementation change routing default SIGINT through the pending interrupt queue. 3. Ruby/spec coverage for default SIGINT -> `Interrupt` and default SIGTERM -> `SignalException` being maskable by `Thread.handle_interrupt`. Once accepted, I would like to request backports for supported Ruby branches where this default SIGINT behavior is present. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:125661] [Ruby Bug#22099] Keyword-only method silently accepts a positional argument
by rumoto (Hiroki Motoyoshi) 09 Aug '26

09 Aug '26

Issue #22099 has been reported by rumoto (Hiroki Motoyoshi). ---------------------------------------- Bug #22099: Keyword-only method silently accepts a positional argument https://bugs.ruby-lang.org/issues/22099 * Author: rumoto (Hiroki Motoyoshi) * Status: Open * ruby -v: ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A method that declares only keyword parameters accepts a positional argument without raising, but only from the second call onward; a prior valid keyword call to the same method is required to trigger it. Once triggered, the positional value is bound to the first keyword and an explicitly passed keyword of the same name is dropped. ```ruby class Foo def bar(a: nil, b: nil) p [:body, a: a, b: b] end end foo = Foo.new foo.bar(a: 1, b: 2) #=> [:body, {a: 1, b: 2}] foo.bar(99, a: 0) #=> [:body, {a: 99, b: nil}] foo.bar(99, b: 0) #=> [:body, {a: nil, b: 99}] ``` Although one positional argument is passed, no exception is raised. The positional value (`99`) is bound to the first keyword `a`, and the explicitly passed keyword (`a: 0` / `b: 0`) is not reflected in the result. Since `bar` accepts no positional arguments, an `ArgumentError (wrong number of arguments (given 1, expected 0))` should be raised. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:125939] [Ruby Bug#22183] parse.y interpolation inside lambda literal
by kddnewton (Kevin Newton) 09 Aug '26

09 Aug '26

Issue #22183 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22183: parse.y interpolation inside lambda literal https://bugs.ruby-lang.org/issues/22183 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is an odd bug that I think is just leaking parse.y internals to do with paren_nest and lambda_beginning_p. In parse.y, `p->lex.lpar_beg` is not isolated when the lexer enters a string interpolation (`tSTRING_DBEG`). So `lambda_beginning_p()` can be true inside an interpolation that appears between a lambda's `->` and its body, causing a `do` or `{` inside the interpolation to be lexed as `keyword_do_LAMBDA` / `tLAMBEG` and produce a syntax error. ```ruby -> a = "#{foo do end}" do end ``` ```console $ ruby --parser=parse.y -c test.rb test.rb: test.rb:1: syntax error found (SyntaxError) > 1 | -> a = "#{foo do end}" do end | ^~ unexpected 'do' for lambda, ... ``` The same applies with a brace block inside the interpolation: ```ruby -> a = "#{foo { }}" do end # parse.y: syntax error at the `{`, lexed as tLAMBEG ``` I'm not 100% sure about this one to be honest. I guess it could potentially have been a design decision? But it seems inconsistent: ```ruby -> a = ("#{foo do end}") do end # parse.y: OK -> a = "#{foo do end}" do end # parse.y: syntax error ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125803] [Ruby Bug#22124] void value missed in parse.y
by kddnewton (Kevin Newton) 09 Aug '26

09 Aug '26

Issue #22124 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22124: void value missed in parse.y https://bugs.ruby-lang.org/issues/22124 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` $ ruby --parser=parse.y -cwe 'x = return a b do end' Syntax OK $ ruby --parser=prism -cwe 'x = return a b do end' ruby: -e:1: syntax error found (SyntaxError) > 1 | x = return a b do end | ^~~~~~~~~~~~~~~~~ unexpected void value expression ``` I think it's likely because of the wrapped block expression. -- https://bugs.ruby-lang.org/

5 4