I'm debugging a reverted transaction on Polygon and this is all the information I have: https://mumbai.polygonscan.com/tx/0xfa86dc4957e3a3da9298b7672b11a20ebe921854fa494dc073920c067c1e693f#internal
If I'm reading it correctly, it seems to be saying that a CREATE2 reverted. But what are some reasons why a CREATE2 can revert? I'm aware that it would revert if something already existed at the address, but this isn't the case here, as you can see from here: https://mumbai.polygonscan.com/address/0x6bb03ca906c0372f384b845bd5ce9ca4327ffbe6
The linked transaction makes a message call (aka internal transaction) to contract deployed at 0x1079b7398b6efd9845c4db079e6fac8d21cf67b3.
This 0x1079b7... contract then tries to deploy a new contract on address 0x6bb03ca906c0372f384b845bd5ce9ca4327ffbe6, you can see the bytecode of the new contract for example in the Tenderly debugger.
As far as I'm aware, create2 can revert for 3 reasons:
Not enough gas left to perform the deployment
Not an issue in this case. Acording to the debugger there was ~9M gas units left and the deployment would take only ~1M gas units.
Deploying contract to address where another contract instance is already deployed.
Because you can predetermine the contract address with create2, this can happen. However not in this case either, the 0x6bb03c... address is empty, there's no contract deployed.
So we're left with uncaught exception during executing the constructor.
pragma solidity ^0.8;
contract MyContract {
constructor() {
require(false);
}
}
A code like this fails the deployment and effectively causes the create2 code to revert.
Unfortunately, without the new contract source code, it's hard to tell what exactly is the cause of constructor revert. Whether it's unexpected length or input params to the constructor, logical error, trying to make a call to non-existing contract, or anything else.
It turns out that I'm misreading Polygonscan and that just because there's a red mark next to an internal transaction doesn't mean that it's the internal transaction itself that reverted; it means that the whole transaction reverted. Anyways, using the Tenderly debugger helped me identity the real bug.
I am testing with rinkiby in ethereum geth environment (using light node.). By building the contract with solidity, the contract has been deployed correctly. If I try to access a function in that instance, I got a "match" error. I don't use "match" anywhere in the program source code, but I don't know which part is the problem. Can I analyze more solidity code?
Upgrade your web3 version.
reference.
I want to write a library which can be callcalled by any contract.
As part of this, I want to write a function which returns the contract address of the library to the contract which callcalled it.
address(this) is normally the solution, but in the case of callcode, it can only be used to check if the contract is being callcalled through if(address(this)==msg.sender) which become always true.
So how to perform this without having to rewrite the code each time because of the requirement to predict the future library’s contract address ?
I am beginning with Solidity and have begun experiencing this problem in my Contract. I created a test case to show the issue(pictured below with console log included) that is also getting the same error. Functions and events are not being recognized in the call graph and I am not quite sure why because they are explicitly there.
I have been attempting to deploy a contract using the Truffle framework, I have recently been testing these contracts on the development network.
My contract was very large and when I attempted to deploy it to a test net, I was instructed to split it up so that the contract wouldn't exceed the gas limit. Although, bearing in mind this contract did deploy onto the development network with the default gas limit.
So I took out parts of the contract and derived another contract from the base and added the deleted sections in there. I attempted to deploy it to the development network in order to test it again, I now get the error:
'Error: The contract code couldn't be stored, please check your gas amount.'
So the steps I took was to:
Change my gasLimit to 100,000,000 which didn't solve it
Check to see if my contract is 'abstract'
My understanding of this is that a contract is abstract if it or its
parent has any functions without an implementation. Mine don't.
I then deleted all of the code other than the constructor from the
derived contract and I still get this error
I deleted the file and the deployment worked with just my base contract as before, therefore the parent contract must not have any non-implemented functions AND it still doesn't work when I attempt to derive an empty contract from it (making sure nothing was abstract in the derived contract).
I then split my migration files up so that the migrations happen
separately, still no luck.
My parent contract is around 300 lines long so no point posting it all in here - I know some people will say 'it may just be too large' however, it deployed when it was 500 lines long on the dev network and now it is only 250 lines long with a deriving contract of 275 lines long, it does not deploy.
The error:
Running migration: 2_deploy_contracts.js
Replacing ERC20Token...
... 0xcae613274de1aa278e7ae5d1239f43445132a417d98765a4f227ea2439c9e4fc
ERC20Token: 0xeec918d74c746167564401103096d45bbd494b74
Replacing Crowdsale...
... 0x0ffc7291d84289c1391a81ed9f76d1e165285e3a3eadc065732aa288ea049b3a
Crowdsale: 0x0d8cc4b8d15d4c3ef1d70af0071376fb26b5669b
Saving successful migration to network...
... 0x7f351d76f61f7b801913f59b808688a2567b64933cdfdcf78bb18b0bf4e4ff69
Saving artifacts...
Running migration: 3_more_deployed_contracts.js
Deploying StagedSale...
... 0x216136bb24d317b140a247f10ec4d6791559739111a85932133cd4a66b12a1d9
Error encountered, bailing. Network state unknown. Review successful
transactions manually.
Error: The contract code couldn't be stored, please check your gas
amount.
at Object.callback
(/usr/local/lib/node_modules/truffle/build/cli.bundled.js:329221:46)
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:39618:25
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:331159:9
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:175492:11
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:314196:9
at XMLHttpRequest.request.onreadystatechange
(/usr/local/lib/node_modules/truffle/build/cli.bundled.js:329855:7)
My base contract is too large to post, and it deploys fine on its own meaning its not abstract.
My derived contract is:
pragma solidity ^0.4.16;
import "./SafeMath.sol";
import "./Crowdsale.sol";
contract StagedSale is Crowdsale {
using SafeMath for uint256;
/*
* Setup the contract and transfer ownership to appropriate beneficiary
*/
function StagedSale
(
uint256 _stage1Duration,
uint256 _stage2Duration
) public {
uint256 stage1duration = _stage1Duration.mul(1 minutes);
uint256 stage2duration = _stage2Duration.mul(1 minutes);
}
My migration file for the derived contract:
var StagedSale = artifacts.require("./StagedSale.sol");
module.exports = function(deployer) {
const stage1Duration = 1;
const stage2Duration = 1;
deployer.deploy(StagedSale, stage1Duration, stage2Duration);
};
I have posted this question here as I fear this may be a common issue with Truffle deployment.
To conclude, I don't believe this has anything to do with the actual gas limits and is instead, failing for some unknown reason and printing this error message anyway.
I've found a fix to this, basically if you are inheriting from a base contract, you must deploy the base contract within the inherited contracts constructor like so:
OLD VERSION:
Simply deployed the base, then deployed the inheriting contract with a reference to 'is Crowdsale' in class name
deployer.deploy(ERC20Token, initialAmount, tokenName, decimalUnits,tokenSymbol).then(function() {
return deployer.deploy(Crowdsale, softCap, hardCap, etherCostOfEachToken, sendFundsTo, toChecksumAddress(ERC20Token.address), durationInMinutes);
});
deployer.deploy(FinalizableSale);
NEW VERSION
Only deploy the inheriting contract and create a new instance of base within that constructor
deployer.deploy(ERC20Token, initialAmount, tokenName, decimalUnits,tokenSymbol).then(function() {
return deployer.deploy(Finalizable, softCap, hardCap, etherCostOfEachToken, sendFundsTo, toChecksumAddress(ERC20Token.address), durationInMinutes);
});
FINALIZABLE CONSTRUCTOR:
function FinalizableSale(uint256 _fundingGoalInEthers, uint256 _fundingLimitInEthers, uint256 _etherCostOfEachToken, address _sendFundsTo, address _tokenAddress, uint256 _durationInMinutes)
Crowdsale(_fundingGoalInEthers, _fundingLimitInEthers, _etherCostOfEachToken, _sendFundsTo, _tokenAddress, _durationInMinutes)
{
//do something
}
NOTE: That the base contract is initialised BEFORE the opening brackets to the constructor function.
I no longer get the 'out of gas' error and my contract runs as before.