Reduce gas limit in estimateGas from 1 Trillion to 10 * block.gas_limit

[jbentke]

I'm running:

• Parity version: 1.7.4
• Operating system: MacOS
• And installed: homebrew

---

Following two contracts are being deployed:

pragma solidity ^0.4.13;

contract Assigner {

    address[] listA;
    address[] listB;

    function finalizeChange() {
        listA = listB;
    }
}

pragma solidity ^0.4.13;

contract Delegate {

    address[] listA;

    address assignerContract = *address of Assigner contract*;
    
    function finalizeChange() {
        require(assignerContract.delegatecall(msg.data));
    }
}

(I stripped the example contracts down to a bare minimum.)

steps to reproduce:

1. deploy the Assigner contract
2. deploy the Delegate contract (adjusting the assignerContract address)
3. run Delegate.finalizeChange().

expected-behavior:
Because listB is not mapped in the Delegate contract, parity should throw an error.

actual-behavior:
Parity will run in some sort of endless loop while consuming 100% CPU in the activity monitor and can not be stopped via ctrl+c.

[rphmeier]

I notice the similarity to the ValidatorSet interface. Is finalizeChange being called in a regular transaction or is this a validator contract which is automatically called by the system?

In the latter case, please note that there is no limit on the amount of computation finalizeChange can do, as the code is essentially included into the consensus process. An infinite loop or similar is generally a bad idea because it will spin forever.

The fact that CTRL-C doesn't kill is definitely a problem, but can probably be solved pretty easily. Right now the IO Workers are waited for on shutdown, where really they could be detached after a certain interval.

[jbentke]

Yes, I came across that error while doing a validatorSet contract, but I also tried it as a normal transaction with the contracts above. Parity "crashed" in both cases.

[jbentke]

I just did some more testing running a ethash network with geth and parity. Sending the transaction through geth does not influence parity. When trying to send the transaction through parity, the cpu usage goes up a lot but does not influence the synching of the client. However it prevent the client from sending any further transactions (tested through ui). Hope this helps narrow down the issue 👍

[rphmeier]

Can you specify more details of the transaction? For example, how much gas was provided, what the gas limit of the chain was at that time, and what the nonce of the transaction and account were?

[jbentke]

Random. I tried it a bunch of times. DId it with dev chain, with ethash and validatorSet (with validatorSet it crashes on chain creation).

[rphmeier]

Can reproduce, but just to make a note first:

with validatorSet it crashes on chain creation

that's intended behavior I would say. introducing an infinite loop or panic into the consensus code, whether at the Rust or EVM level is going to do that. We can fix Rust issues here, but correctness of ValidatorSets are the responsibility of their authors.

---

Seems that estimateGas stalls when presented with an infinite loop like the one above and a minimal one here:

contract InfiniteLoop {
    function infiniteLoop() public {
        while (true) {}
    }
}

because it first tries to execute the transaction with block.gas_limit gas and if that fails then tries to execute with 1 TRILLION gas. Obviously that will spin for a long time.

We should have a more sensible fallback after block.gas_limit fails. I understand the motivation to produce estimates beyond the block gas limit, but maybe a constant multiple of N * block.gas_limit as a maximum would be safer.

[arkpar]

The high boundary used to be 50 million. Maybe just revert to that? N would be about 10

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 0.16 ETH (92.13 USD @ $575.79/ETH) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $8,941.94 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Cancelled

---

Work has been started.

These users each claimed they can complete the work by 8 months, 2 weeks ago.
Please review their action plans below:

1) omar408 has started work.

O.C

Learn more on the Gitcoin Issue Details page.

[rphmeier]

is this not done already? https://github.com/paritytech/parity/blob/master/ethcore/src/client/client.rs#L1465

[vs77bb]

@omar408 Could you please clarify your approach here?

Also thanks for the thought @rphmeier - if it's already implemented, we can pull the bounty here and re-allocate it elsewhere 🙂

[vs77bb]

@folsen Would you mind confirming if this is already complete? If not, I will make sure this gets back in front of Gitcoiner's who may want to pick it up. 😄

[rphmeier]

closed in #7075

[gitcoinbot]

Issue Status: 1. Open 2. Cancelled

---

The funding of 0.16 ETH (89.62 USD @ $560.13/ETH) attached to this issue has been cancelled by the bounty submitter

• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $11,721.56 more funded OSS Work available on the Gitcoin Issue Explorer