Currently, our maintainer is failing to call SendRewards on mainnet:
Error while performing maintenance.
Solana RPC client returned an error:
Request: Some(SendTransaction)
Kind: RPC response error
Error code: -32002
Message: Transaction simulation failed: Error processing Instruction 0: Program failed to complete
Reason: Transaction preflight failure
Error:
Raw: InstructionError(0, ProgramFailedToComplete)
Display: Error processing Instruction 0: Program failed to complete
Logs:
Program BNVB8pd4coHpY7MVcrtiHLCLst7fyDGzMtPmfJqFAhwj invoke [1]
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [2]
Program log: Instruction: Approve
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 2026 of 153383 compute units
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success
Program BNVB8pd4coHpY7MVcrtiHLCLst7fyDGzMtPmfJqFAhwj consumed 52383 of 200000 compute units
Program failed to complete: Access violation in stack frame 3 at address 0x200003fe8 of size 8 by instruction #19763
Program BNVB8pd4coHpY7MVcrtiHLCLst7fyDGzMtPmfJqFAhwj failed: Program failed to complete
We saw this access violation before, it is caused by a stack overflow. We ran into this in SendRewards previously and we already optimized it to reduce stack usage, but I suspect the late addition of some metrics increased the size of the Anker struct which pushed it over the edge again.
Changes
Add a test that reproduces the stack overflow and fails in case it happens. The test calls SendRewards which will fail either way in our test context because we don’t have the Wormhole program and all its dependent accounts available there. (Setting up a token swap instance was hard enough, I don’t think it is feasible to get a working Wormhole instance in the test context.) But we can tell apart the failure due to stack overflow from the failure due to trying to call a non-existing program.
Make the test pass by boxing a few more things to free up stack space.
Problem
Currently, our maintainer is failing to call
SendRewardson mainnet:We saw this access violation before, it is caused by a stack overflow. We ran into this in
SendRewardspreviously and we already optimized it to reduce stack usage, but I suspect the late addition of some metrics increased the size of the Anker struct which pushed it over the edge again.Changes
SendRewardswhich will fail either way in our test context because we don’t have the Wormhole program and all its dependent accounts available there. (Setting up a token swap instance was hard enough, I don’t think it is feasible to get a working Wormhole instance in the test context.) But we can tell apart the failure due to stack overflow from the failure due to trying to call a non-existing program.