Index -1 out of bounds for length 0
#900
Comments
|
seems same issue as #877 |
|
this error happens on 2250385 This block has a single tx and the zktracer finds this error when checking the sender: ValidationResult{invalidReason=Optional[UPFRONT_COST_EXCEEDS_BALANCE], errorMessage=Optional[transaction up-front cost 0xb6447b9791cb93 exceeds transaction sender account balance 0xe3b390101c37c]} Because of this, the tx is not traced, and given it's the only transaction, the tracer creates a BlockSnapshot with no tx. And then it leads to the out of bound exception. |
|
when getting the conflated trace from block 2250131 to block 2250478, The sender balance of 0x6186bff11ac9acc75724b3c11f7ac0c13de7f3bd is set as 0x000000000000000000000000000000000000000000000000000e3b390101c37c before the tx of the above block is executed. If we retrieve the conflated trace for block 2250385 alone, then it is 0x00000000000000000000000000000000000000000000000000b6475b85e1edc7 and it's enough for the upfront cost, hence the tx passes. This means that while the conflated trace from 2250131 to 2250385, the balance of the sender is not computed properly. |
|
we can reproduce the error with the smaller range the error is most likely while evaluating tx: https://lineascan.build/tx/0x5cc8d84bd0d5be9e84eb857c3a571293b202f4e2c5e6b046e6f857bc9958ab38 |
|
For some reason, the MainnetTransactionProcessor computes a balance of 0x000000000000000000000000000000000000000000000000000e3b390101c37c post the transaction and the refund, but when we retrieve the balance through rpc call we get a different value: curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x6186bff11ac9acc75724b3c11f7ac0c13de7f3bd", "2250351"],"id":53}' http://127.0.0.1:15480 I stop investigating here as i don't know what more to look at. |
|
@FlorianHuc time curl --location --request POST 'http://127.0.0.1:15480' --header 'Content-Type: application/json' --data-raw '{"jsonrpc": "2.0","method": "linea_generateConflatedTracesToFileV2","params": [{"startBlockNumber": 2250131,"endBlockNumber": 2250478,"expectedTracesEngineVersion": "0.4.0-rc1"}],"id": 1}' {"jsonrpc":"2.0","id":1,"error":{"code":-32603,"message":"Plugin internal error","data":"relBlock has invalid value (256) |
|
with tracer v0.5.0-beta now we get this error message below. |
|
@gusiri @FlorianHuc So I can repeat what you have above and see the same failure. However, I can still get the trace for that file by using a different RPC method (following what the existing #!/bin/bash
START_BLOCK=$1
END_BLOCK=$2
METHOD='linea_captureConflation'
NODE='ec2-18-117-9-115.us-east-2.compute.amazonaws.com:15480'
DATA="{\"jsonrpc\": \"2.0\",\"method\": \"$METHOD\",\"params\": [$START_BLOCK,$END_BLOCK],\"id\": 1}"
echo "Fetching traces for blocks $START_BLOCK ... $END_BLOCK"
curl -X POST --data "$DATA" $NODE | jq '.result.capture' -r | jq . | gzip > $START_BLOCK-$END_BLOCK.json.gzNote that you have to have
Of course, its because you are generating the actual |
|
Also, on |
|
So... seems like
are actually related and we are trying to solve the same problem. |
|
@gusiri I'm not sure I want to say they are the same issue yet. A few things:
|
|
Maybe the answer here is to actually look inside an |
|
Test 2 only runs conflation-related methods, and Test 1 also runs conflation after replay(). So, I assumed Test 2 was a subset of Test 1? I know we have different issues in replay(), which might be preventing us from observing these errors in the conflation-related methods. |
|
Also, the latest Is this because we touched |
|
Trying to get the |
|
@DavePearce @FlorianHuc Just checked that this error in With the full original range Let me narrow down the block range. |
|
@gusiri Ok, so here's a test which shows the replay test mechanism is definitely broken, and that the traces coming from the BESU node better reflect mainnet:
This is showing that all transactions succeed --- unlike for the replay test where one of them fails. I also confirmed that there are exactly three transactions in the trace. Also, the replay files from the BESU node versus the shadow node are showing the same problems with unexpectedly reverting transactions. |
|
@DavePearce Thank you for the debugging and comparison, David. It was really informative. Things are now clearer than before. |
|
We And I also found something interesting here. Current status:
When I divided the range into smaller ranges:
So, the range is a bit larger than what can be configured in Besu or ZkTracer, I guess? |
|
Actually it is :) @DavePearce @FlorianHuc With 255 blocks : Success
|
|
conflation |
|
@gusiri And now we come full circle. So, having identified another bug (#998) and fixing it temporarily on my branch, then executing the replay That looks kinda familiar. So I must be on the right track now :) |
|
@DavePearce It really is a full circle :) It's a 'welcome' error message. Looks good! |
Ranges
Spotted by @gusiri
The text was updated successfully, but these errors were encountered: