parity trace_transaction showing internal calls incorrectly

[mtbitcoin]

the parity trace for http://etherscan.io/vmtrace?txhash=0x7725f11b932394f67bb07dcecff9bda0dd529a4a12a98be7cf418de8d36bb2d8&type=parity shows 2 internal calls

While, a similiar trace against geth shows no calls http://etherscan.io/vmtrace?txhash=0x7725f11b932394f67bb07dcecff9bda0dd529a4a12a98be7cf418de8d36bb2d8

The address is 0x2ab9f67a27f606272189b307052694d3a2b158ba is EOA (not a contract address) and shouldn't be generating any internal calls ?

[mtbitcoin]

As a follow up, i run a few different nodes all with the following

C:>"C:\Program Files\Ethcore\Parity\parity.exe" --tracing on --port 30305 --jsonrpc-port 8546 --max-peers 20 --no-signer --no-dapps
2016-08-20 14:05:51 Starting Parity/v1.3.0-beta-425e1ce-20160812/x86_64-windows-msvc/rustc1.10.0

On some nodes, it shows the internal calls, but others do not. Could this be an indexing issues with db ? The same trace produces inconsistent results across different nodes. Might be related to https://github.com/ethcore/parity/issues/1958

The other possibility is that this is related to the chain reorgs and parity not updating the traces correctly in these instances? I noticed that in both previous instances there were chain reorgs during those blocks

[mtbitcoin]

Removing all the chain data and re syncing solves the issue, might be related to the chain re-organizations/forks and traces not getting updated/stored correctly after the re-organizaiton

[gavofyork]

right. @debris ?

[gavofyork]

@mtbitcoin what version(s) of parity were you running?

[mtbitcoin]

Starting Parity/v1.3.0-beta-425e1ce-20160812/x86_64-windows-

The issue does not happen consistently on all block reorgs, but only on certain occasions which also appear to coincide with the chain reorgs

[mtbitcoin]

this is another transaction where the issue occurs http://etherscan.io/vmtrace?txhash=0x521dfb716af4f7c123e16f9d35f435620d91ab905207263b21dd7502ef30cb80&type=parity

on a 4 different nodes running parity, 3 showed the above 1 did not

[debris]

Thanks! These logs are much more helpful. I can see a pattern now

[mtbitcoin]

@debris nice, hopefully we can get this resolved. I will however need to purge the trace above shortly. So please copy it down if you still need it.

[mtbitcoin]

@debris Here is another one if you are looking for more patterns http://etherscan.io/vmtrace?txhash=0xc6022991c3245d93ab9a23f17bc87fdd753b13e61b0796d8e53b5109d9bf3d47&type=parity

The second call should not have been there

note: I've tried running the latest nightly build and the issue is still present

[debris]

I've noticed few things.

1. Bug occurs only when 'canon block' and 'forked block' has the same transactions, but transactions order is different.
2. Traces belong always to a different transaction than the one asked for. But it is always transaction from the same block.

---

I need your help with few more things:

1. I assume that order of transactions on this page is not random: http://etherscan.io/txs?block=2155075 . What method is displayed to get these transactions hashes? Which client is used? Is it geth or parity? I'm asking cause the order of transactions using my local parity node is completely different:

   "transactions": [
       "0x4907bb67a0e73713546bf1002d1debcc65e33477ce9dd216bdfe05179dd61dfd",
       "0x8d47ffdbbbb278810c6741ba1e47d5c8f32d49b0faf555a9847fa3110548cb8d",
       "0xd357925b2170eac77e55c2575440cd17f33d71893bae178ce9f530b2579d150b",
       "0x6d1874d1543f5148e2beda20a84792bd6215e1ba5ea774dcab4e0ef6b3417318",
       "0x2d1864e05a35db3df85cb5aa7ba1c58603d7b5704d0f0b8fd8186855aa5ef79c",
       "0x64a49d5b03e12636a64345fdd76906a599044cced43acefedecce10d73e4fb18",
       "0x064432d5a0690de3015cd68acf4ddf06390f0508314e361318336c2aafb0dad7",
       "0x5f9030955265f3ba9a73a0e420acdae76308f7c71824b021d840dc2f102b7aaa",
       "0x916cd1069570f14ad3f90e9a75308ec91b098e15c6a8b1a8471b1016dc138b10",
       "0x521dfb716af4f7c123e16f9d35f435620d91ab905207263b21dd7502ef30cb80",
       "0x23711d378ac48c50b09da74615cfe7c99c8039bf6b5b03c5bce865f6cb7f6ce3"
     ]
   

2. Can you describe, step by step, what API methods do you use to collect trace data? eg.

• call getheth_getBlockByNumber
• call parityeth_getBlockByNumber
• fetch transactions traces from parity client using trace_block method.

---

Conclusion:

This bug is definitely chain reorg issue. I don't know yet, what causes it. I also don't know if parity is the only affected client. I assume that parity is affected, cause you mentioned 4 different nodes running parity, 3 showed the above 1 did not.

I have an assumption, regarding what's happening on etherscan.io, please correct me if I'm wrong. You fetch block from geth client. Then you assume (correctly!), that transactions in parity are in the same order. You attach parity traces to geth's transactions, just looking at transaction index in given block. This causes mismatches in UI.

[debris]

@mtbitcoin we found the bug. We are working on fixing it

[mtbitcoin]

@debris do you still need the info above ?

[debris]

no ;)

[debris]

It should be fixed on master. Soon will merged to beta. Please reopen if you notice problems again

[mtbitcoin]

@debris slightly unrelated, but noticed that the blocks seem to be coming in slower than normal. Did anything change? or perhaps this is because it's the unstable version vs beta ?