Anchor program works locally but 'Access violation in stack frame 5' on devnet: unactivated stack feature gate

Symptom: an instruction that creates several accounts runs fine under anchor test and a manually started solana-test-validator, but on devnet/mainnet it fails with Access violation in stack frame 5 at address 0x200005db8 of size 8. Compilation produced no Stack offset of N exceeded max offset of 4096 warning, so it looks like a cluster bug.

Cause: the local validator activates all feature gates by default, while clusters activate them on a schedule. The relevant one here is EenyoWx9UMXYKpR8mW5Jmfmy2fRjzUtM7NduYMY8bx33, which changes SBF stack-frame handling (see anza-xyz/agave issue #1186). With it off, the cluster enforces the 4KB per-frame stack limit your code was quietly exceeding — a genuine stack overflow in your program, just invisible locally. Reported with Anchor 0.29 / Solana 1.18.

Reproduce locally, which is the key move:

solana-test-validator -r --deactivate-feature EenyoWx9UMXYKpR8mW5Jmfmy2fRjzUtM7NduYMY8bx33

Fix: shrink stack usage — Box<Account<'info, T>> the large accounts in your #[derive(Accounts)] struct so they live on the heap, avoid large local arrays/structs, and split fat instructions.

Generalize the technique: whenever behaviour differs between localnet and a cluster, diff feature sets (solana feature status -u d vs -u l) and selectively deactivate features locally with --deactivate-feature. Specific feature IDs age out as gates activate everywhere, so check the current activation schedule rather than assuming this exact ID still matters in 2026.

Source: adapted from a Stack Exchange answer by Jonas H. (question by GregoryWhale), https://solana.stackexchange.com/questions/15555/fails-on-devnet-works-on-localnet-access-violation-in-stack-frame-5-at-address — CC BY-SA 4.0