Bug #22414
open
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
Description
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.
No data to display