The process Parity-evm is terminated automatically when it detect an "infinite loop"

[BattleBird]

when I use the binary parity-evm to run the following code, the following bytecode contains an "infinite loop"

./parity-evm_2_7_2 stats --json --code 608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063f8a8fd6d146044575b600080fd5b348015604f57600080fd5b506056606c565b6040518082815260200191505060405180910390f35b600080600590505b600181111560975760005481600054020160008190555080806001019150506074565b600054915050905600a165627a7a72305820810334636e12aa50d47379b457fc760db3ea8b8d7541586bb61159e81632ba880029 --input f8a8fd6d

• OpenEthereum version: 2.7.2
• Operating system: Linux
• Installation: built from source

• Fully synchronized: no

  actual

expected behavior I know restricting the gas limit is the only way to detect (or rather protect against) infinite loops. However, in this example, the program has enough gas limit to keep running. Why the process is terminated automatically? steps to reproduce the issue._ ./parity-evm_2_7_2 stats --json --code 608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063f8a8fd6d146044575b600080fd5b348015604f57600080fd5b506056606c565b6040518082815260200191505060405180910390f35b600080600590505b600181111560975760005481600054020160008190555080806001019150506074565b600054915050905600a165627a7a72305820810334636e12aa50d47379b457fc760db3ea8b8d7541586bb61159e81632ba880029 --input f8a8fd6d

[adria0]

Hi @BattleBird,

Probably this is happening due to some internal overflow, infinite loops with "infinite gas" is not a covered precondition for this binary.

[BattleBird]

Hi @BattleBird,

Probably this is happening due to some internal overflow, infinite loops with "infinite gas" is not a covered precondition for this binary. Hi adria0,

Thanks for your reply! I have another question. For a parity-node with RPC-endpoints, If I invoke a transaction which contains an "infinite loop" via openethereum client with enough gas limit, may the client crash due to some internal overflow? Thanks:)

[BattleBird]

Hi @BattleBird,

Probably this is happening due to some internal overflow, infinite loops with "infinite gas" is not a covered precondition for this binary.

I run the same bytecode and input on evm binary in go-ethereum, go-ethereum will print trace information and terminate the operation correctly until the gas limit is used up. Go-ethereum don't require allocating mew memory, is there any defect in parity-evm implementation?

[adria0]

@BattleBird,

Depending on the bytecode, the result could be different between OE and Geth when using the evm binary tools. I am not aware about the exact details of those differences, but for instance: ORIGIN opcode pushes different values, the starting gas are not the same by default, geth is pushing a virtual STOP when executing at the end of code, etc...

Are you executing both clients the same gas? Which set of opcodes are you using? Are you querying pre-existing state values?

[BattleBird]

@BattleBird,

Depending on the bytecode, the result could be different between OE and Geth when using the evm binary tools. I am not aware about the exact details of those differences, but for instance: ORIGIN opcode pushes different values, the starting gas are not the same by default, geth is pushing a virtual STOP when executing at the end of code, etc...

Are you executing both clients the same gas? Which set of opcodes are you using? Are you querying pre-existing state values?

Here is the control flow graph in the following bytecode, we can observe there exists an infinite loop in block 0x74, and the loop opcodes sequences look like this, both clients has enough gas. Why a simple infinite loop can cause an OutofMemoryError?

[BattleBird]

@BattleBird,

Depending on the bytecode, the result could be different between OE and Geth when using the evm binary tools. I am not aware about the exact details of those differences, but for instance: ORIGIN opcode pushes different values, the starting gas are not the same by default, geth is pushing a virtual STOP when executing at the end of code, etc...

Are you executing both clients the same gas? Which set of opcodes are you using? Are you querying pre-existing state values?

ps: the set of codes sequence is as following, Why a simple infinite loop can cause an OutofMemoryError in the OE?

[adria0]

Probably the memory is filled with the traces. All traces are stored in memory to be dumped at the end of execution.

[BattleBird]

Probably the memory is filled with the traces. All traces are stored in memory to be dumped at the end of execution.

Will the memory dump attack affect the OE client?

[adria0]

This does not affect the OE client