-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Corruption: block checksum mismatch / during sync. #7766
Comments
cc @andresilva this happens during sync follow-up on #7334 cc @DeviateFish-2 also #7748 |
Another sample for the pile (running v1.9.0):
(for the record, the lack of a second stack trace for the initial crash is not a mistake, there was no stack trace produced) Again, going to reiterate, this is happening during a sync (full archive sync in my case, as seen in the output when restarting), and without any input at all. This is not the result of shutting down parity while it is syncing (inadvertently or otherwise). The corruption is happening during the sync process, which is causing parity to exit. I'm capturing a full log right now, and will update this comment with it when it crashes. As an aside... why does parity log to stderr? [Edit] Here's a full log: |
It is possible that not closing RocksDB properly on shutdown could lead to some silent corruption, if there's no crash on shutdown you'll only see that corruption whenever RocksDB has to write to that block in the future (which might be the case here). This is my best explanation so far, we have a fix for RocksDB not being properly closed on shutdown which will be out in the next release and I'd like to see if these corruption issues disappear or reduce in frequency. |
Why would that be the case here? The corruption is what's causing the shutdown of parity in these cases, not the other way around. Look at the logs: I'm not stopping parity and then encountering corruption on restart. Parity is crashing due to corruption. I've done what I can do rule out hardware issues, but of course cannot completely rule them out. However, this seems to be a relatively frequent occurrence--#7334 was originally opened as a report of this behavior, and many of the issues closed as duplicates of it are also instances of crashes during initial sync. These aren't cases where someone or something is forcibly terminating parity, and thus causing corruption due to an unclean shutdown. These are cases where parity itself is crashing, presumably due to corruption. |
Maybe I didn't explain myself properly. Every single shutdown of parity until #7695 was an unclean shutdown, regardless of whether you would see a crash or not. RocksDB would not be properly closed. The error you're seeing doesn't mean the database is being corrupted during sync, it means you're finding corrupted data during the sync, the corruption could have happened at any other time. I'm not saying that there isn't any other cause for the corruption, but this is currently my best explanation since this was a violation of the RocksDB API (not closing the database properly), and assuming you use the RocksDB API properly it shouldn't lead to data corruption (short of hardware faults or RocksDB bugs). If you're willing to help please do a |
How would it have happened at "another time" if this is a fresh sync (e.g. empty You can look at the logs I've provided. Literally every one of these samples I've provided has been following a I've said this in literally every report that this is a clean sync, from scratch, with no pre-existing data. Please fucking read a little better.
|
@DeviateFish-2 Sorry, I wasn't aware of that, disregard what I said in that case. |
Here's the @5chdn Could you re-open this issue? |
Yep. Thanks for the logs. |
Is this issue being resolved anytime soon? I haven't been able to sync for MONTHS because of this issue and can confirm it's not a Hardware issue. I've had the same issue happen with 2 different SSDs and 6 different HDDs. Same problem no matter where the Parity database is stored. Can provide more logs if needed. |
@Emperornero which version? on start up or during sync? |
This has been happening since 1.7.6, no DB clears seem to fix the problem, currently on 1.9.2. |
Ditto. version Parity/v1.9.2-beta-0feb0bb-20180201/x86_64-linux-gnu/rustc1.23.0 Tried full sync of mainnet/foundation. It stalled out about 12 hours in (2.4m blocks). Issued clean shutdown (ctl-c). Shut the VM down until this morning. Attempted restarting Parity this morning and received the same database corrupted database messages as everyone else.
|
I have created an issue in RocksDB with the logs that @DeviateFish-2 provided (facebook/rocksdb#3509). @DeviateFish-2 I understand that you've tried to rule out hardware issues by switching hard drives and memory. @Emperornero did you try to rule out faulty memory? Could you run a memtest? |
I don't know if it matters, but I'm running Parity in a Parallels 12 VM (Ubuntu 16.04) on a Macbook Pro running macOS 10.13.1 I've allocated 8GB ram to the VM (Parity appears to be a memory hog). With a 60GB vhd (on the laptop's internal SSD). |
Duplicate of #7748 |
I had this same issue for days. I fixed the issue by removing 1 stick of my ram. Now my laptop has only 1 stick of 8GB DDR3 installed, and Parity syncs without an issue. Wish this helps! |
Starting from a clean slate latest stable and unstable versions 1.8.7 / 1.9.0 the following error is occuring at different block heights? Could this be faulty hardware?
The text was updated successfully, but these errors were encountered: