Closed anajuliabit closed 1 week ago
Can you give some more details on your code and specific test? A minimal reproduction would greatly help as I'm unable to reproduce it.
For context, the error thrown is on line which points to sload
: https://github.com/bluealloy/revm/blob/1640b8f6989d0d4a19dfeb343e7967d501f6e195/crates/revm/src/journaled_state.rs#L634
@zerosnacks
I'm having this error while using both 'forge test' and 'forge script'. One of the scripts that I'm having trouble with is this:
contract ValidateCalldata is Script {
function run() public virtual {
Addresses addresses = new Addresses("./addresses/Addresses.json");
GovernorBravoDelegate governor = GovernorBravoDelegate(
addresses.getAddress("PROTOCOL_GOVERNOR")
);
uint256 proposalId = vm.parseUint(vm.prompt("Proposal ID"));
(uint256 id, , , , , , , , , ) = governor.proposals(proposalId);
console.log("Proposal ID: ", id);
string memory proposalPath = vm.prompt("Proposal path");
Proposal proposal = Proposal(deployCode(proposalPath));
proposal.run();
}
}
You could fork this branch an run the script https://github.com/solidity-labs-io/forge-proposal-simulator/pull/60
The application panicked (crashed).
Message: called `Option::unwrap()` on a `None` value
Location: /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/revm-8.0.0/src/journaled_state.rs:634
This is a bug. Consider reporting it at https://github.com/foundry-rs/foundry
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⋮ 8 frames hidden ⋮
9: core::panicking::panic::h3131e0868b9f8622
at <unknown source file>:<unknown line>
10: core::option::unwrap_failed::hdb518deb484b6610
at <unknown source file>:<unknown line>
11: revm::journaled_state::JournaledState::sload::h8e49b14ff456d23b
at <unknown source file>:<unknown line>
12: <revm::evm::Evm<EXT,DB> as revm_interpreter::host::Host>::sload::h14a38b6e4759241c
at <unknown source file>:<unknown line>
13: revm_interpreter::instructions::host::sload::h0aa46a59c974d770
at <unknown source file>:<unknown line>
14: revm::inspector::handler_register::inspector_instruction::{{closure}}::hf6f6326c515f05f9
at <unknown source file>:<unknown line>
15: revm::evm::Evm<EXT,DB>::transact::h3e054478c389d33e
at <unknown source file>:<unknown line>
16: foundry_evm::executors::Executor::call_raw::h261240ba57942724
at <unknown source file>:<unknown line>
17: forge_script::runner::ScriptRunner::call::h0140cf02babf6c14
at <unknown source file>:<unknown line>
18: forge_script::execute::PreExecutionState::execute::{{closure}}::h265410e9338ecab4
at <unknown source file>:<unknown line>
19: forge_script::ScriptArgs::run_script::{{closure}}::hb6fea62893c80fe3
at <unknown source file>:<unknown line>
20: forge::main::hc93306eec46cd029
at <unknown source file>:<unknown line>
21: std::sys_common::backtrace::__rust_begin_short_backtrace::h7c3c93c18a7c8aef
at <unknown source file>:<unknown line>
22: _main<unknown>
at <unknown source file>:<unknown line>
Thank you!
looks like this is happening in scrip @klkvr
@anajuliabit sorry this is a bit hard to reproduce without knowing details about your project structure. mind giving any hints on how to setup local anvil node for the failing script? or maybe there is a failing repro not requiring external inputs?
@klkvr There is no need to use a local anvil node. You can run:
forge script script/ValidateCalldata.s.sol --rpc-url sepolia -vvvv
Then, pass 2
to the proposal ID prompt and examples/governor-bravo/BRAVO_01.sol
to the proposal path prompt.
The issue here is that you are switching forks inside of Prososal
contract which is not persistent. Adding a simple vm.makePersistent(address(proposal))
solved this for me.
cc @mattsse do you think there is a way we can show more user-friendly errors for such internal EVM violations?
first step could be to disallow switching forks if caller contract is not persistent
I tried mitigating this with a few checks in the backend's fork switching logic, but looks like we're missing another edge case
for example:
the revm evm relies on certain constraints and usually the unwraps are fine, but with fork modifications there can be edge cases where this is no longer true
I'd need a repro test case for this in order to debug
@klkvr @mattsse @zerosnacks thank you very much!
@mattsse hmm, I believe env.tx.caller
is tx.origin
and we need msg.sender
validation here probably?
that makes sense, so we also need to load this?
Original issue has been resolved
Updated description to reflect the proposed further changes
Hi @anajuliabit
We've since made a change that automatically marks contracts that modify the forks are marked as persistent, see: https://github.com/foundry-rs/foundry/issues/8004, fixed by https://github.com/foundry-rs/foundry/pull/8041
For now marking as resolved by https://github.com/foundry-rs/foundry/pull/8041
Would you mind seeing if you are still able to reproduce the issue against the latest version of Foundry? If so, please leave a comment / re-open the issue.
Thanks!
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge 0.2.0 (1ca9b85 2024-04-15T02:39:06.470405000Z)
What command(s) is the bug in?
forge test
Operating System
macOS (Apple Silicon)
Describe the bug
Application panicked when running forge test on files that use deployCode cheatcode