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

[ruby-core:116589] [Ruby master Misc#20238] Use prism for mk_builtin_loader.rb
by kddnewton (Kevin Newton) 13 Mar '26

13 Mar '26

Issue #20238 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20238: Use prism for mk_builtin_loader.rb https://bugs.ruby-lang.org/issues/20238 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I would like to propose that we use prism for mk_builtin_loader.rb. Right now the Ruby syntax that you can use in builtin classes is restricted to the base Ruby version (2.7). This means you can't use a lot of the nicer syntax that Ruby has shipped in the last couple of years. If we switch to using prism to parse the builtin files instead of using ripper, then we can always use the latest version of Ruby syntax. A pull request for this is here: https://github.com/kddnewton/ruby/pull/65. The approach for the PR is taken from how RJIT bindgen works. -- https://bugs.ruby-lang.org/

6 22

[ruby-core:123871] [Ruby Feature#21700] `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful
by trinistr (Alexander Bulancov) 12 Mar '26

12 Mar '26

Issue #21700 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Feature #21700: `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful https://bugs.ruby-lang.org/issues/21700 * Author: trinistr (Alexander Bulancov) * Status: Open ---------------------------------------- *This was supposed to be a bug report, but it turned into a feature request halfway through.* `IO::Buffer.map` supports `size` and `offset` arguments to localize buffer to a specific part of mapped file. While `size` works fine, specifying `offset` as anything but 0 is a recipe for disaster. 1. It is practically undocumented. This is it currently: "Optional size and offset of mapping can be specified." While `size` can be whatever user desires, `offset` can only be set to specific values. It was *very* surprising when I started testing it, as I expected it to behave similar to size and offset of a slice. Which values are allowed? That's the next point. 2. Possible values for `offset` are highly platform-dependent. - On Linux it must be a multiple of page size. (https://www.man7.org/linux/man-pages/man2/mmap.2.html) - On macOS it can be any value? manpage doesn't specify exactly. (https://developer.apple.com/library/archive/documentation/System/Conceptual… (I looked at the manpage on a mac, seems to be the same.)) - On Windows it must be a multiple of some value that *isn't* page size and page size doesn't work here. StackOverflow says it's 64 kB, but that didn't work for me. (See dwFileOffsetLow in https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-…) - On other systems? Who knows. 3. On macOS, a buffer successfully created with an offset crashes on read. I don't know why, it's exactly the same file, size and offset that works on Ubuntu, and the read is bounded. 4. Currently, offset doesn't change the buffer's size if unspecified, leading to crashes. I will be making a PR addressing this but still. 5. All of this makes offset unpractical to test, leading to all kinds of problems. So the problem is: this argument is a very low-level detail that requires significant knowledge of all platforms your code may be ever deployed to, even if strictly Ruby is used (no C API), with unexpectedly high footgun potential. I understand that IO::Buffer is a lower-level class, but this seems too much. I propose to make `offset` argument into a convenience for users, allowing any reasonable value (i.e inside the file). Behind the scenes, we can use the native offset for efficieny, on platforms where it works well, but the user API would be decoupled from this. However, I'm not particularly familiar with Ruby internals, so I can't tell how viable this is. -- https://bugs.ruby-lang.org/

2 4

[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: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: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:124741] [Ruby Bug#21873] `UnboundMethod#==` returns false for methods obtained via extend + unbind
by mdalessio (Mike Dalessio) 07 Mar '26

07 Mar '26

Issue #21873 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #21873: `UnboundMethod#==` returns false for methods obtained via extend + unbind https://bugs.ruby-lang.org/issues/21873 * Author: mdalessio (Mike Dalessio) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description `UnboundMethod#==` returns `false` when comparing a module's instance method against the same method obtained via `Method#unbind` on a class that includes or extends that module, despite having the same owner and source location. ```ruby module MyMethods def hello = "hello" end class Base extend MyMethods end from_module = MyMethods.instance_method(:hello) from_unbind = Base.method(:hello).unbind p from_module.owner == from_unbind.owner #=> true p from_module.source_location == from_unbind.source_location #=> true p from_module.inspect == from_unbind.inspect #=> true p from_module == from_unbind #=> false (expected true) ``` ## Diagnosis `method_eq` compares method entries using `method_entry_defined_class`. For methods mixed in via `include`/`extend`, the "defined class" will be an ICLASS and not the original class/module. In the example above, `method_eq` is comparing a module's ICLASS entry against the module, and that will always be false. Related: #18798 (fixed by @ko1 in 59e389af). -- https://bugs.ruby-lang.org/

6 6

[ruby-core:124673] [Ruby Bug#21860] Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup`
by byroot (Jean Boussier) 07 Mar '26

07 Mar '26

Issue #21860 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21860: Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup` https://bugs.ruby-lang.org/issues/21860 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- We recently observed some deadlocked processes. These got deadlock during child initialization right after `Process.fork`. Based on the `gdb` session, the child is deadlocked in `threadptr_interrupt_exec_cleanup`, which suggest `th->interrupt_lock` was locked by another thread in the parent, and wasn't reinitialized in the children before calling `threadptr_interrupt_exec_cleanup`. ```c (gdb) bt 20 #0 0x0000ffff855a09c0 in __lll_lock_wait () from /lib64/libc.so.6 #1 0x0000ffff855a6d60 in pthread_mutex_lock@@GLIBC_2.17 () from /lib64/libc.so.6 #2 0x0000aaaaaeec04c8 [PAC] in rb_native_mutex_lock (lock=<optimized out>) at /ruby-3.4.4/thread_pthread.c:116 #3 threadptr_interrupt_exec_cleanup (th=<optimized out>) at thread.c:6052 #4 thread_cleanup_func_before_exec (th_ptr=0xffff35803000) at thread.c:514 #5 thread_cleanup_func (atfork=1, th_ptr=0xffff35803000) at thread.c:524 #6 terminate_atfork_i (current_th=0xffff84e1e000, th=0xffff35803000) at thread.c:4769 #7 rb_thread_atfork_internal (atfork=<optimized out>, th=0xffff84e1e000) at thread.c:4736 #8 rb_thread_atfork () at thread.c:4779 #9 0x0000aaaaaee110fc [PAC] in after_fork_ruby (pid=0) at process.c:1693 #10 rb_fork_ruby (status=status@entry=0x0) at process.c:4253 #11 0x0000aaaaaee11154 [PAC] in proc_fork_pid () at process.c:4266 #12 rb_proc__fork (_obj=<optimized out>) at process.c:4313 #13 0x0000aaaaaeefeb7c [PAC] in vm_call_cfunc_with_frame_ (stack_bottom=0xffff84e7a1c8, argv=0xffff84e7a1d0, argc=0, calling=<optimized out>, reg_cfp=0xffff84f79150, ec=0xffff84e31050) at /ruby-3.4.4/vm_insnhelper.c:3794 #14 vm_call_cfunc_with_frame (ec=0xffff84e31050, reg_cfp=0xffff84f79150, calling=<optimized out>) at /ruby-3.4.4/vm_insnhelper.c:3840 #15 0x0000aaaaaef1aa44 [PAC] in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /ruby-3.4.4/vm_callinfo.h:415 #16 vm_exec_core (ec=0xffff84e31050) at /ruby-3.4.4/insns.def:1063 #17 0x0000aaaaaef0aa58 [PAC] in rb_vm_exec (ec=ec@entry=0xffff84e31050) at vm.c:2595 #18 0x0000aaaaaef0fe48 [PAC] in vm_call0_body (ec=ec@entry=0xffff84e31050, calling=calling@entry=0xffffea5a1e78, argv=argv@entry=0x0) at /ruby-3.4.4/vm_eval.c:225 #19 0x0000aaaaaef136e8 in vm_call0_cc (kw_splat=0, cc=0xfffeee654508, argv=<optimized out>, argc=0, id=27393, recv=281472906794680, ec=0xffff84e31050) at /ruby-3.4.4/vm_eval.c:101 ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124699] [Ruby Bug#21866] Backport Fix for integer overflow checks in enumerator
by rwstauner (Randy Stauner) 07 Mar '26

07 Mar '26

Issue #21866 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #21866: Backport Fix for integer overflow checks in enumerator https://bugs.ruby-lang.org/issues/21866 * Author: rwstauner (Randy Stauner) * Status: Open * Assignee: rwstauner (Randy Stauner) * Target version: 4.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- I would like to backport this PR https://github.com/ruby/ruby/pull/15829 that has already merged to master. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123913] [Ruby Bug#21711] Prism and parse.y parses private endless method definition with block differently
by tompng (tomoya ishida) 07 Mar '26

07 Mar '26

Issue #21711 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21711: Prism and parse.y parses private endless method definition with block differently https://bugs.ruby-lang.org/issues/21711 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the following code, `do end` block is passed to `private` in Prism but passed to `tap` in parse.y ~~~ruby private def f = tap do end f # different result(prism: LocalJumpError, parsey: returns main) ~~~ According to https://bugs.ruby-lang.org/issues/17398#note-10, `private def hello = puts "Hello" do expr end` should be parsed as `private (def hello = puts "Hello") do expr end`. This is correctly implemented in both Prism and parse.y, but when rhs is `tap do end`, there is a discrepancy. Another example. Prism: parse success, parse.y: syntax error. ~~~ruby private def f = 1 do end ~~~ -- https://bugs.ruby-lang.org/

2 2