Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Stage 5 block verification failed for #8455037 #9402

Closed
pabloruiz55 opened this issue Aug 22, 2018 · 8 comments
Closed

Stage 5 block verification failed for #8455037 #9402

pabloruiz55 opened this issue Aug 22, 2018 · 8 comments
Labels
F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust.
Milestone

Comments

@pabloruiz55
Copy link

pabloruiz55 commented Aug 22, 2018

I'm running:

  • Which Parity version?: v1.11.8
  • Which operating system?: MacOS
  • How installed?: via installer
  • Are you fully synchronized?: no
  • Which network are you connected to?: kovan
  • Did you try to restart the node?: yes

Out of the sudden I started to get this today.

2018-08-22 11:20:23  Stage 5 block verification failed for #8455037 (0x4870…e8ea)
Error: Error(Block(InvalidGasUsed(Mismatch { expected: 0x3674a, found: 0x32cbc })), State { next_error: None, backtrace: None })
2018-08-22 11:20:49  Syncing #8455036 0x1adc…952d     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed  #8455021    2/25 peers   31 KiB chain 2 MiB db 0 bytes queue 12 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
2018-08-22 11:21:19       #1042    0/25 peers   31 KiB chain 2 MiB db 0 bytes queue 12 KiB sync  RPC:  0 conn,  0 req/s,   0 µs
2018-08-22 11:21:49       #1042    0/25 peers   31 KiB chain 2 MiB db 0 bytes queue 12 KiB sync  RPC:  0 conn,  0 req/s,   0 µs

Tried:

  • deleting nodes.json
  • using --no-warp
  • deleting the whole kovan chain folder
  • doing db kill

Whatever I do I always get to the point that after the snapshots are synced I get the errors above and then no sync will happen (#0, 0 peers)

Any ideas?

@roninkaizen
Copy link

roninkaizen commented Aug 22, 2018

hey there,
sometimes as it "falls down to such a connection rate rate,
i extract the "working-peers" from the nodes.json file
and set them as reserved-peers-
which works since eta 14 days with two parallel main-chain/kovan-chain "split.nodes"-
the error with the "Stage 5 block verification failed for #8455037 (0x4870…e8ea)"-
is completely new to me and
with Block verification errors i am not familiar with,
i would assume that the disc used
could have errors or is too small somehow.

@Tbaut
Copy link
Contributor

Tbaut commented Aug 23, 2018

Same as #8506
I looks like you only get connected to misbehaving peers. --no-warp should help you to ignore those. Does is always happen on this exact same block?

@Tbaut Tbaut added F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust. labels Aug 23, 2018
@Tbaut Tbaut added this to the 2.1 milestone Aug 23, 2018
@pabloruiz55
Copy link
Author

Yes, always exact same block. Also started an EC2 instance and getting the exact same issue there...

Tried doing a a no warp but at block #1000002 I always get a Stage 3 error and same behaviour.

@Tbaut
Copy link
Contributor

Tbaut commented Aug 23, 2018

Tried doing a a no warp but at block #1000002 I always get a Stage 3 error and same behaviour.

Ok, this is is the same as #9403 and being worked on.

@felixwatts
Copy link

felixwatts commented Oct 21, 2018

I have some information and a workaround that might be useful:

  • I got this problem when using a new version of parity with a base-dir created by a very old version.

  • parity db kill failed with error message "Error removing database: Os { code: 2, kind: NotFound, message: "No such file or directory" }"

  • I fixed the problem by manually deleting base-dir/chains/kovan/db

@JohannesMayerConda
Copy link

Tried it again today using parity --chain kovan db kill and then parity --chain kovan and it synced correctly. I guess because it started the Syncing after Snapshot Sync with block #9140067 wich is later than my trouble causing #9120001 block.

For me the workaround was waiting for the snapshot to pass the bad block

@felixwatts
Copy link

felixwatts commented Oct 21, 2018 via email

@Tbaut
Copy link
Contributor

Tbaut commented Oct 22, 2018

Closing as it simply appears to be a misbehaving node you are connected to.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

No branches or pull requests

6 participants