Use less stack intensive error mapping

[Henry-E]

closes: #2070

[vercel]

Someone is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[andreihrs]

lgtm! I reproduced this and seems like these changes fix the #2070 issue.

I was using https://github.com/andreihrs/anchor-error-reprod with all the accounts uncommented in OracleMappings struct. When I was running "cargo test-bpf", I was getting Program failed to complete: Access violation in stack frame 5 at address 0x200005ea0 of size 8 by instruction #2425 from anchor 0.25

With your latest fix, the tests pass properly. Thanks for this!

Maybe we can introduce a similarly sized account in tests to make sure other don't run into this issue again.

Much appreciated!

[Henry-E]

Great, I'll have to see if we can introduce downstream tests or include this one perhaps if it doesn't have too many other dependencies. Another more general solution is really just to be more conscious of heap usage in anchor, e.g. map_err is not good for heap usage because it automatically adds the error struct to the heap even if nothing is called. Or something roughly like that. It's similar to error_or_else where you want it to error lazily.

[snawaz]

I'm using anchor 0.26.0 which is supposed to include the fix in this PR (?). However, cargo build-sbf still gives me similar error messages:

Error: Function ZN14solana_program4vote5state9VoteState11deserialize17hc24c28c4eff79cffE Stack offset of 6344 exceeded max offset of 4096 by 2248 bytes, please minimize large stack variables
Error: Function ZN229$LT$solana_program..vote..state..vote_state_0_23_5....$LT$impl$u20$serde..de..Deserialize$u20$for$u20$solana_program..vote..state..vote_state_0_23_5..VoteState0_23_5$GT$..deserialize..__Visitor$u20$as$u20$serde..de..Visitor$GT$9visit_seq17h90250e16ba5fe33dE Stack offset of 5752 exceeded max offset of 4096 by 1656 bytes, please minimize large stack variables
Compiling voting-app v0.1.0 (/Users/snawaz/projects/voting-app/programs/voting-app)
Finished release [optimized] target(s) in 2.19s

Implies, this PR doesn't fix in all places?

[Henry-E]

This PR was fixing a stack error that was showing up for a limited range of programs for a very specific reason, it was introduced by a change made to anchor about showing errors.

No matter what anchor does as a dev you will always be able to exceed the stack. It's a memory buffer allowed to you by the solana runtime. If you're getting a stack error then you should follow the instructions and try to box accounts which will put them on the heap.

However, if there's a specific part of anchor you think might be causing this, like if there's some function or variables that are unnecessarily using up memory, then we can definitely look at fixing that. You would need to help us in tracking down / narrowing where the excessive memory usage was coming from in the anchor lang/ directory.