edr icon indicating copy to clipboard operation
edr copied to clipboard

Issue with the receive function

Open hyeonLewis opened this issue 1 year ago • 0 comments

I'm using hardhat with [email protected] and found the following issues related to the receive function.

When the receive() payable has a modifier that uses a private function and is expected to be reverted, the EDR can't recognize the fallback. The existing function with payable (callMe in the example below) works as expected. Please check the below PoC.

PoC
// SPDX-License-Identifier: MIT
pragma solidity 0.8.25;

contract Test {
    bool public isReverted;

    modifier revertIf() {
        require(!isReverted, "I'm reverted"); // No issue when directly check the condition
        _;
    }

    function setIsReverted(bool _isReverted) external {
        isReverted = _isReverted;
    }

    function callMe() external payable revertIf {}

    receive() external payable revertIf {}
}
--- a/contracts/Mock/Test.sol
+++ b/contracts/Mock/Test.sol
@@ -5,7 +5,7 @@ contract Test {
     bool public isReverted;
 
     modifier revertIf() {
-        require(!isReverted, "I'm reverted");
+        _checkReverted(); // Issue occurred when using private function
         _;
     }
 
@@ -16,4 +16,8 @@ contract Test {
     function callMe() external payable revertIf {}
 
     receive() external payable revertIf {}
+
+    function _checkReverted() private view {
+        require(!isReverted, "I'm reverted");
+    }
 }
  • Testing script:
it.only("#fallback: PoC", async function () {
  const { deployer, test } = await loadFixture(TestFixture);

  await test.setIsReverted(true);

  await expect(deployer.sendTransaction({ to: test.target, value: 100 })).to.be.revertedWith("I'm reverted");
});
  • Testing result:
❯ export RUST_BACKTRACE=full
❯ hh test

thread '<unnamed>' panicked at crates/edr_solidity/src/error_inferrer.rs:1164:17:
This shouldn't happen: trying to get fallback source reference from a contract without fallback
stack backtrace:
   0:        0x13ecbce34 - _napi_register_module_v1
   1:        0x13ecd931c - _napi_register_module_v1
   2:        0x13ecba184 - _napi_register_module_v1
   3:        0x13ecbcce8 - _napi_register_module_v1
   4:        0x13ecbda54 - _napi_register_module_v1
   5:        0x13ecbd898 - _napi_register_module_v1
   6:        0x13ecbe208 - _napi_register_module_v1
   7:        0x13ecbde94 - _napi_register_module_v1
   8:        0x13ecbd2f8 - _napi_register_module_v1
   9:        0x13ecbdb74 - _napi_register_module_v1
  10:        0x13ed1da64 - _napi_register_module_v1
  11:        0x13e8ca69c - <unknown>
  12:        0x13e8c9118 - <unknown>
  13:        0x13e8c6688 - <unknown>
  14:        0x13e8c1b20 - <unknown>
  15:        0x13e8e372c - <unknown>
  16:        0x13e8e18c4 - <unknown>
  17:        0x13e63f5dc - <unknown>
thread '<unnamed>' panicked at core/src/panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
   0:        0x13ecbce34 - _napi_register_module_v1
   1:        0x13ecd931c - _napi_register_module_v1
   2:        0x13ecba184 - _napi_register_module_v1
   3:        0x13ecbcce8 - _napi_register_module_v1
   4:        0x13ecbda54 - _napi_register_module_v1
   5:        0x13ecbd898 - _napi_register_module_v1
   6:        0x13ecbe208 - _napi_register_module_v1
   7:        0x13ecbde94 - _napi_register_module_v1
   8:        0x13ecbd2f8 - _napi_register_module_v1
   9:        0x13ecbdb74 - _napi_register_module_v1
  10:        0x13ed1da98 - _napi_register_module_v1
  11:        0x13ed1db10 - _napi_register_module_v1
  12:        0x13ed1dbfc - _napi_register_module_v1
  13:        0x13e63f834 - <unknown>
thread caused non-unwinding panic. aborting.

hyeonLewis avatar Apr 29 '25 06:04 hyeonLewis