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