Go-ethereum: Regression in 1.8.x: call to contract with ecrecover/sha256 always returns `0x`

[lionello]

This bug manifests itself by RPC decoding errors such as the one returned by web3:

Error: Couldn't decode address from ABI: 0x

System information

Geth version: Geth/v1.8.1-stable-1e67410e/darwin-amd64/go1.9.4
OS & Version: OSX 10.13.3 (17D47)

Expected behaviour

eth.call (eth_call) should return the result of the operation.

Actual behaviour

The string 0x is returned.

Steps to reproduce the behaviour

• Get the repro code from https://gist.github.com/lionello/522e6a583e373ac745ee55f265380908
• Run a Geth node on localhost with RPC on port 8545

geth --dev --rpc --rpcapi personal,eth

• Run ./repro181.js (nodeJS)

Backtrace

The Geth console shows only the following message with --verbosity:

DEBUG[02-26|16:29:52] Executing EVM call finished              runtime=183.253µs
DEBUG[02-26|16:29:52] Executing EVM call finished              runtime=209.303µs
DEBUG[02-26|16:29:52] VM returned with error                   err="evm: execution reverted"
DEBUG[02-26|16:29:52] Executing EVM call finished              runtime=209.662µs

[lionello]

Interestingly, sendTransaction appears to work just fine, with the exact same payload as the call, which suggests that the error happens in the encoding of the return value.

[lionello]

Confirmed OK for 1.7.3 and before

[lionello]

Confirmed broken since Geth/v1.8.0-stable-5f540757/darwin-amd64/go1.9.4

[lionello]

From console:

> eth.call({data:"0x21f158037e568cb5eedc46ac087c6a291e108dd621f1569893269b478caf31658ce0568a000000000000000000000000000000000000000000000000000000000000001bd01a67d067f3725e592851a3ceb4203c95da65ba99e76de1d2cfd5a94084272e3eeb83a3d715689a2187cdc11fbde44dff6a27b77d71a86a1c68fa04374d2362",to:"0x5E01ad2dEA731f04E552211ED9D88b41f4Cf7029"}) DEBUG[02-26|17:51:24] Recalculated downloader QoS values       rtt=20s confidence=1.000 ttl=1m0s

TRACE[02-26|17:51:24]                                          msg="sending {\"jsonrpc\":\"2.0\",\"id\":58,\"method\":\"eth_call\",\"params\":[{\"data\":\"0x21f158037e568cb5eedc46ac087c6a291e108dd621f1569893269b478caf31658ce0568a000000000000000000000000000000000000000000000000000000000000001bd01a67d067f3725e592851a3ceb4203c95da65ba99e76de1d2cfd5a94084272e3eeb83a3d715689a2187cdc11fbde44dff6a27b77d71a86a1c68fa04374d2362\",\"to\":\"0x5E01ad2dEA731f04E552211ED9D88b41f4Cf7029\"},\"latest\"]}"
DEBUG[02-26|17:51:24] VM returned with error                   err="evm: execution reverted"
DEBUG[02-26|17:51:24] Executing EVM call finished              runtime=334.922µs
TRACE[02-26|17:51:24]                                          msg="<-readResp: response {\"jsonrpc\":\"2.0\",\"id\":58,\"result\":\"0x\"}"
"0x"

[lionello]

Compare with sendTransaction:

eth.sendTransaction({data:"0x21f158037e568cb5eedc46ac087c6a291e108dd621f1569893269b478caf31658ce0568a000000000000000000000000000000000000000000000000000000000000001bd01a67d067f3725e592851a3ceb4203c95da65ba99e76de1d2cfd5a94084272e3eeb83a3d715689a2187cdc11fbde44dff6a27b77d71a86a1c68fa04374d2362",to:"0x5E01ad2dEA731f04E552211ED9D88b41f4Cf7029",from:"0x21b1a00C1cA48E115E89e8805a99Eb8270B8C082"})
TRACE[02-26|17:49:42]                                          msg="sending {\"jsonrpc\":\"2.0\",\"id\":14,\"method\":\"eth_sendTransaction\",\"params\":[{\"data\":\"0x21f158037e568cb5eedc46ac087c6a291e108dd621f1569893269b478caf31658ce0568a000000000000000000000000000000000000000000000000000000000000001bd01a67d067f3725e592851a3ceb4203c95da65ba99e76de1d2cfd5a94084272e3eeb83a3d715689a2187cdc11fbde44dff6a27b77d71a86a1c68fa04374d2362\",\"from\":\"0x21b1a00C1cA48E115E89e8805a99Eb8270B8C082\",\"to\":\"0x5E01ad2dEA731f04E552211ED9D88b41f4Cf7029\"}]}"
TRACE[02-26|17:49:42] Pooled new future transaction            hash=8167c9…c80f28 from=0x21b1a00C1cA48E115E89e8805a99Eb8270B8C082 to=0x5E01ad2dEA731f04E552211ED9D88b41f4Cf7029
TRACE[02-26|17:49:42] Promoting queued transaction             hash=8167c9…c80f28
INFO [02-26|17:49:42] Submitted transaction                    fullhash=0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28 recipient=0x5E01ad2dEA731f04E552211ED9D88b41f4Cf7029
TRACE[02-26|17:49:42] Broadcast transaction                    hash=8167c9…c80f28 recipients=0
TRACE[02-26|17:49:42]                                          msg="<-readResp: response {\"jsonrpc\":\"2.0\",\"id\":14,\"result\":\"0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28\"}"
"0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28"
> INFO [02-26|17:49:42] Commit new mining work                   number=7 txs=1 uncles=0 elapsed=598.977µs
TRACE[02-26|17:49:42] Waiting for slot to sign and propagate   delay=-541.036ms
INFO [02-26|17:49:42] Successfully sealed new block            number=7 hash=bc680f…6d19d3
DEBUG[02-26|17:49:42] Trie cache stats after commit            misses=12 unloads=0
INFO [02-26|17:49:42] 🔗 block reached canonical chain          number=2 hash=5b00b9…0e104c
INFO [02-26|17:49:42] 🔨 mined potential block                  number=7 hash=bc680f…6d19d3
TRACE[02-26|17:49:42] Propagated block                         hash=bc680f…6d19d3 recipients=0 duration=2562047h47m16.854s
TRACE[02-26|17:49:42] Announced block                          hash=bc680f…6d19d3 recipients=0 duration=2562047h47m16.854s
DEBUG[02-26|17:49:42] Reinjecting stale transactions           count=0
TRACE[02-26|17:49:42] Removed old pending transaction          hash=8167c9…c80f28
INFO [02-26|17:49:42] Commit new mining work                   number=8 txs=0 uncles=0 elapsed=429.268µs
WARN [02-26|17:49:42] Block sealing failed                     err="waiting for transactions"
DEBUG[02-26|17:49:44] Recalculated downloader QoS values       rtt=20s confidence=1.000 ttl=1m0s
> eth.getTransactionReceipt("0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28")
TRACE[02-26|17:50:03]                                          msg="sending {\"jsonrpc\":\"2.0\",\"id\":16,\"method\":\"eth_getTransactionReceipt\",\"params\":[\"0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28\"]}"
TRACE[02-26|17:50:03]                                          msg="<-readResp: response {\"jsonrpc\":\"2.0\",\"id\":16,\"result\":{\"blockHash\":\"0xbc680f4d190bb9b2947d1f187b569bfcdc90a7317b319e44b8dffe10826d19d3\",\"blockNumber\":\"0x7\",\"contractAddress\":null,\"cumulativeGasUsed\":\"0x7e4a\",\"from\":\"0x21b1a00c1ca48e115e89e8805a99eb8270b8c082\",\"gasUsed\":\"0x7e4a\",\"logs\":[],\"logsBloom\":\"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\"status\":\"0x1\",\"to\":\"0x5e01ad2dea731f04e552211ed9d88b41f4cf7029\",\"transactionHash\":\"0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28\",\"transactionIndex\":\"0x0\"}}"
{
  blockHash: "0xbc680f4d190bb9b2947d1f187b569bfcdc90a7317b319e44b8dffe10826d19d3",
  blockNumber: 7,
  contractAddress: null,
  cumulativeGasUsed: 32330,
  from: "0x21b1a00c1ca48e115e89e8805a99eb8270b8c082",
  gasUsed: 32330,
  logs: [],
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  status: "0x1",
  to: "0x5e01ad2dea731f04e552211ed9d88b41f4cf7029",
  transactionHash: "0x8167c9a8e5dd2eb069c649476289f92568702420c4cadda52e60d42116c80f28",
  transactionIndex: 0
}

Notice the status: "0x1" in the receipt.

[lionello]

Another data point: the bug happens with both PoA (clique) and --dev chain on 1.8.x

[djken2006]

eth_call to contract with sha256 always returns 0x too.

[lionello]

@djken2006 Yup, I'm seeing the same thing here. Guys, this is a major issue!

[karalabe]

Thanks for the repro, looking into it!

[karalabe]

Thank you all, found the issue. eth_call-s are running currently with gas metering disabled, but some code still checks the gas. We moved around certain gas calculations, which resulted in some gas getting 0, and the "other" code which still checked for gas rejected it with OOG.

I've opened https://github.com/ethereum/go-ethereum/pull/16229 as a potential solution. It's not the best as it incurs gas calculation costs previously not present. I still think though it's the cleaner solution.

[lionello]

How is this not covered in tests :(

[karalabe]

There is a comprehensive consensus suite covering just about every aspect of the EVM. However those tests work with live transactions, not with eth_call invocations. Generally the two should be the same, however as the present bug shows there was a behavioral diversion. The only way to catch these issues would be to run the consensus tests with eth_call too, but that would just double the work and apart from very rare scenarios, wouldn't catch anything that transaction execution doesn't.

[AlexanderShniperson]

also didn't work with 1.7.x we need fix asap for our project

[lionello]

@karalabe That's impossible: from the user point of view, transactions don't return the output of smart contract call, so most Dapps will want to do an eth_call right before doing a eth_sendTransaction. How are return values covered in the tests, if not with eth_call?

[karalabe]

@lionello Nested calls?

[PhABC]

I apologize @karalabe for reopening, but would the following error be related to the current issue?

https://www.reddit.com/r/ethdev/comments/82p78k/two_identical_arguments_for_function_call_one/

Note that this is happening on the Rinkeby network.

Edit : Seems like a solidity compile bug, sorry for the confusing. See /solidity/#3687

[razaden]

Hello @karalabe I think this issue is still unresolved. I will explain my case.
My contract invokes the sha256() function. If I am working with the Javascript VM or the Ganache-cli VM,
the return value of the sha256() is correct. However, if I connect remix to my local geth private blockchain instance, the return value of the sha256() function is always "0x". This appears to be an issue with precompiled contracts, as sha3() works fine without any issues in all cases.
I have allocated, in the genesis file of my private blockchain, a 1 wei balance to all precompiled contract addresses, however, the issue still persists.
How can I address this issue?
I am sorry if my reporting is not proper, this is my first time commenting on an issue. I am available to provide any specifics that you might ask.
Thank you.

[davux]

Any update on this? I can see this was asked to be reopened but still in close state on the tracker. What's the actual state of this bug?