Access violation in stack frame when compiling program with any solana version greater than 1.18.0

[anthontaylor]

Problem

I run into Access violation in stack frame errors anytime I compile my program with a solana version greater than 1.18.0. This includes the latest version 1.18.12. #252 Mentions the issue but it looks like some of us are still running into it. I tested the issue using a vanilla solana program instruction with minimal # of accounts and still see it.

Related issue in anchor
coral-xyz/anchor#2835 (comment)

Proposed Solution

[adrena-orex]

We've experienced the same issue, and believe it's caused by the ix using too much stack size. We have noticed that the init accounts takes a lot of stack. Can't have more than 3/4 accounts to init within the same instruction. Had to split some ix + use zero_copy to make ixs to work again.

orex> solana --version
solana-cli 1.18.11 (src:c78a9720; feat:3469865029, client:SolanaLabs)
orex> anchor --version
anchor-cli 0.29.0

Started having the issue after migrating from solana 1.16.16 and anchor 0.28.0 to solana 1.18.11 and anchor 0.29.0.

Using https://github.com/anza-xyz/platform-tools/releases v1.41 to compile.

Note: Everything works fine on testnet, when deploying on devnet today, error rise again. Removed one more account and it worked.

orex> solana cluster-version                                                                                             
1.18.12
orex> solana config get
Config File: /Users/orex/.config/solana/cli/config.yml
RPC URL: https://api.devnet.solana.com 
WebSocket URL: wss://api.devnet.solana.com/ (computed)
Keypair Path: /Users/orex/.config/solana/id.json 
Commitment: processed

[LucasSte]

I believe the problem is fixed is platform tools version v1.41. You can check the version of your tools using running cargo-build-sbf --version.

Either way, can you provide an example code that triggers the problem?

[etodanik]

@LucasSte for us we're still getting this with 1.41 (on 1.18.15 version)

[LucasSte]

Duplicate of #1186 (all ongoing efforts to fix the issue are being discussed there).