-
Notifications
You must be signed in to change notification settings - Fork 35.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Corruption: block checksum mismatch #6528
Comments
These are disk corruption issues: leveldb keeps its own checksums of all data it writes, when it notices during (background) compaction that these mismatch it will return the error on the next flush.
|
Same issue here, but with Win10 x64. Checkdisk returned no errors on disk. |
The support team of the VPS hosting provider claims there are no disk corruption issues:
|
Silent corruption in raid arrays is absolutely possible. Its possible this is an issue with leveldb, but it seems more likely there are silent errors somewhere in your disk/raid controller/etc. |
Have seen something similar in dogecoin/dogecoin#1216 - could be specific to our changes, but the version in question is a complete rebuild around Bitcoin Core 0.11. Either way, am looking into this, if we find anything we will of course push fixes into Bitcoin as well. |
@jorisbontje Is it possible that you ran out of memory or the disk was full? |
@sipa enough disk space (50GB+). I was expecting an out of memory (only 3GB total), but didn't get an Out of memory error anywhere. I configured the relay settings to reduce the pending tx pool, but still happening. I can try to reproduce this with a |
Joris: does the crash happen while you are synchronizing/running, or after
a stop/start?
If so, could you try running with -par=1 (to reduce risk for CPU problems,
but I don't think that is the problem here, you'd get validation errors
instead).
My last guess would be an incompatibility between LevelDB and the
filesystem yo're using.
|
This happened again while synchronizing/running
|
I'm experiencing similar problem. Ubuntu 12.04.5 on a physical box, software raid. |
I have the same problem here. It all started with the following message "ERROR: AcceptToMemoryPool: non-final". Then after stopping bitcoind I get this message |
@miguelmorales85 what kind of filesystem / storage setup do you have? (raid, vps, simfs, etc) |
@jorisbontje the hd was formated in ext4 |
I have the same issue. and I don't have disk corruption. This is Bitcoin Core 0.11 (64-bit), and on Windows 2008 R2 (64-bit), NTFS. I have about 1TB free. 2015-09-14 08:42:33 UpdateTip: new best=0000000000000000184d37ea91dc37ad61f2c9eca556020476787bf9916a5a24 height=337433 log2_work=81.923139 tx=55737117 date=2015-01-04 11:54:53 progress=0.635931 cache=62.6MiB(10952tx) |
Again database corruption at block 252.dat |
I have just failed to reindex bitcoind.. this is what happened. can somebody help me. Please dont tell me I have to reindex AGAIN... |
@miguelmorales85 it is highly likely you have hardware problems |
@jgarzik I ran e2fsk on the unmounted partition in a live session with 0 errors :( |
Firstly, I created my account because of this issue. |
I finally finally did not get the checksum mismatch after several reindexing (like a week of try and error). But now the node keeps getting STALLED, I have can not SYNC the node. The closer I got was like verification progress to 0.9989xxxx and I am slowly going down... Can somebody help me? I have restarted the node, reboot the Ubuntu PC and I just get the node UP and then STALLED. Of course I am accepting conections. |
Miguel: anything in debug.log mentioning invalid blocks?
|
@sipa Hello, I have run "cat /home/USER/.bitcoin/debug.log | grep invalid" what can I do about it? |
That almost certainly means Bitcoin Core incorrectly decided that a
signature or transaction was invalid in a block, and subsequently marked
the block invalid.
Can you try reindexing with -par=1 or par=1 in bitcoin.conf?
|
oh god... I feared you would say that... Ok .. will do. See you in a few days. Thanks. |
Hello @sipa I have reindexed. I have the same problem, I can never get to SYNC the node. At this moment the node progression is at 0.9983xxxx and going down and down every seccond... it's going to Stall again. So no par=1 in bitcoin.conf did something to prevent my problem. |
Hi, Here is the last log on yestersay: When this occurred next time, I'll pull new sources from master branch and try again. |
With bitcoind 0.11.1 on a 64-bit Linux PC I got the "Corruption: block checksum mismatch" error. |
Have the same on Ubuntu 15.04 x64 + Bitcoin core 0.11.1.0 (VM 2GB ram, enough hard drive space, ram check OK). First it happened 2 days ago (24hr client just receiving info most of the time), I deleted last 3 blk filed, reindex started, on -2y30w throws "error reading from database". Yesterday I cleared btc data directory except bitcoin.conf and wallet.dat files, moved btc directory to different physical drive with zfs, after resync from scratch it throws "error reading from database" on -2y30w again.
Several guys from bitcointalk.org faced the same problem too (https://bitcointalk.org/index.php?topic=1288944.0 https://bitcointalk.org/index.php?topic=1281530.0 https://bitcointalk.org/index.php?topic=1152996.0) UPDATE: Looks like it's my hardware problem, cancelling bitcoin code claims. |
I have this issue on a fresh install of debian jessie/sid. It's happening with bitcoin, litecoin and dogecoin. It happens on btrfs, changing filesystem to ext4 and redownloading the blochain helped. |
I have looked at my logs and this probably has to do with changing the libdb version. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621425 |
I had the same problem on a Mac Mini (mid 2011) running OS X 10.11.2 with all updates installed, 8 GB RAM. It was consistent; neither -reindex nor deleting the entire blockchain and re-downloading would get around the corrupted database problem, no matter how many times I tried. However, replacing the 0.11.2 software with 0.10.3 (64 bit) worked, after I ran the 0.10.3 with -reindex. So there is something in 0.11.2 that doesn't like my machine, but I can work with 0.10.3 for now. |
We are having the same problem and it is recurring. All other clients seem fine (Litecoin, Dogecoin, Unobtanium etc) - it seems to only be affecting bitcoin. 2016-01-22 16:30:51 Leaving block file 424: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01) "version" : 110200, |
I have tried changing libdb versions on a debian sid machine and only bitcoin is being affected as of now. Dogecoin and every other wallet are fine. |
Changing libdb won't fix this: the backing database for the utxo set and block index is leveldb, not berkeleydb. |
FYI: I had the same issue with v0.11.0 on AMD64 Debian Jessie Linux with ext4 on LUKS file system (Bitcoin-Qt compiled by me). I ran memtest86 and found a couple of faults in my RAM. I disabled 2 sections of 64kB of misbehaving RAM in the GRUB configuration, restarted, and started re-indexing with Bitcoin. Re-indexing took almost a week on my computer; every 8 hours or so I stopped Bitcoin, made a backup of the databases and restarted(*) Bitcoin, just in case something went wrong halfway or at 99%, to prevent having to start re-indexing again. However, I did not encounter any problems during re-indexing, so for me, the problem is solved. If you are always encountering issues during re-indexing on the same position in the block chain, could it be that there is something wrong in the block files stored on your hard disk? In that case, would it be possible to resolve the issue by removing a certain range of block files, to force Bitcoin to re-download these blocks? WARNING: this is just guess-work, and certainly not a recommendation! I'm not that much of an expert, and from my POV this might as well make things worse. (*) On 2nd, 3rd etc. start of Bitcoin, I did not provide the re-index commandline argument, since I did not want to re-start indexing every time. Apparently, Bitcoin automatically continues re-indexing if re-indexing was unfinished on the last shutdown. |
Reindexing with -par=1 solved it for me on MacOS running 0.11.2. The only interesting thing my side is that when I had the error for the first time I had just finished re-downloading the whole chain using 0.11.2, after upgrading from 0.11.1. I did not need to re-download, I just did it (it is not relevant why). This would seem to suggest it is a problem that - at least on Mac - arose from 0.11.2. From people's descriptions though it seems to me we may be in front of more than one issue. The range of symptoms is wide and inconsistent. G. |
Same problem. 0.12.1 Win7 x64 2016-04-21 22:05:08 Corruption: block checksum mismatch |
I have the same problem :(
|
Update: this problem went away when I replaced the memory (RAM) in my computer. The old memory was found to have errors by memtest (data mismatch error). The new memory has no such errors according to memtest. Bitcoin Core has been running 24/7 for weeks now with no problems on a Mac Mini (Mid 2011, 2.3 GHz Intel Core i5, 16 GB 1600 MHz DDR3 memory, OS X 10.11.4). |
Discovered that I was getting some very occasional single-bit errors when reading from disk, so that was likely the cause of this error for me. I underclocked my system by 3.76%, and now I am unable to reproduce the single-bit errors, so hopefully my "block checksum mismatch" issues will be gone now too. |
I had the same error i fixed it by formatting my disk to f2fs from ext4. |
This appears to be entirely related to hardware failures. Closeable @borisbontje |
with
bitcoind
0.11.0 on a 64bit Linux VPS (with simfs)This is occasionally happening after a
-reindex
on 0.11.0, as this was also previously happening on earlier releases.bitcoind.conf
includes settings preventing transaction flooding:The text was updated successfully, but these errors were encountered: