Skip to content

add repro for cu issue (do not merge)#297

Draft
kevinheavey wants to merge 1 commit into
masterfrom
cu-fix
Draft

add repro for cu issue (do not merge)#297
kevinheavey wants to merge 1 commit into
masterfrom
cu-fix

Conversation

@kevinheavey

Copy link
Copy Markdown
Collaborator

@Aursen sharing progress so far

@procdump

procdump commented Feb 18, 2026

Copy link
Copy Markdown
Contributor

Two more eyes here on the issue @Aursen , @kevinheavey - anza-xyz/agave#10659. Do you plan to switch LiteSVM to BPFLoaderUpgradeable?

@procdump

Copy link
Copy Markdown
Contributor

@Aursen

Aursen commented Feb 26, 2026

Copy link
Copy Markdown
Collaborator

@kevinheavey , @Aursen - anza-xyz/agave#10659 (comment)

Thank you for the help

@cds-amal

Copy link
Copy Markdown
Contributor

Hey 👋 @kevinheavey & @Aursen ,

I was looking for a way to recover the feature set as of a given epoch (for replaying older transactions) and found this PR/Issue.

Have you considered the feature set a transaction runs under? Each activation can meaningfully change a transaction's CU, and mainnet_feature_set() means mainnet today, not mainnet at the snapshot's slot, so any capture that predates an activation replays under rules the chain wasn't using yet.

This snapshot appears to predate two of them:

  • SIMD-0266 (Efficient Token program, replace_spl_token_with_p_token):
    the saved simulation logs show classic SPL token costs (TransferChecked at
    6238 CU), so leaving the swap active would replay Tokenkeg on a different
    implementation entirely.
  • SIMD-0339 (Increase CPI Account Infos Limit,
    increase_cpi_account_info_limit): it changes CPI translation
    charging in solana-program-runtime/src/cpi.rs from actual-data-length to
    fixed-size accounting, which would surface as a small per-CPI difference
    in the caller's meter. Might be worth checking whether deactivating it
    closes part of the residual here.

The nice property is that the snapshot already witnesses its own epoch: the saved logs price CPIs the pre-0339 way, no activation-date lookup required. Which suggests the feature set belongs in the snapshot alongside the accounts and programs, recorded at capture time (or at least settable per replay), so a saved repro stays true indefinitely instead of drifting as mainnet activates features.

And if loader shape and feature epoch were both controlled, whatever remains would point at separate axes worth eliminating in turn: builtin instruction base costs, and bundled program builds (token-2022 here) differing from the bytes deployed at the captured slot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants