Assertion `!"cannot load block from disk"' failed

welshjf commented at 9:28 pm on June 9, 2015: contributor

Running bitcoin-qt 0.10.0rc3, 64-bit Linux, official build (sorry about the old version). Died with message:

0bitcoin-qt: main.cpp:3323: void ProcessGetData(CNode*): Assertion `!"cannot load block from disk"' failed.

Tail of debug.log:

02015-06-08 15:57:17 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=181.197.164.66:8333, peer=10275
12015-06-08 15:57:18 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=181.197.164.66:8333, peer=10276
22015-06-08 15:57:22 socket send error Connection reset by peer (104)
32015-06-08 15:57:36 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=181.197.164.66:8333, peer=10277
42015-06-08 15:58:15 receive version message: /bitcoinj:0.12/GetGems:1.0/: version 70001, blocks=360009, us=127.0.0.1:8333, peer=10278
52015-06-08 15:58:15 Added time data, samples 200, offset -346 (-5 minutes)
62015-06-08 15:59:10 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=181.197.164.66:8333, peer=10279
72015-06-08 15:59:17 receive version message: /getaddr.bitnodes.io:0.1/: version 70002, blocks=360009, us=181.197.164.66:8333, peer=10280
82015-06-08 15:59:18 socket send error Connection timed out (110)
92015-06-08 16:00:07 ERROR: ReadBlockFromDisk : OpenBlockFile failed

In case it’s relevant, my disk space is a little low – 91% used, 51G free, ext4.

I’ve restarted and it seems to be syncing OK.

jonasschnelli commented at 7:06 am on June 10, 2015: contributor

Disk space is fine. You probably had/have a disk issue. Try to run fsck.

welshjf commented at 11:32 am on June 10, 2015: contributor

fsck only checks metadata. I just did a bitcoind -checkblocks=0 -checklevel=0 which looks like at least as thorough a check as what failed before. It completed without errors. Trying level 1 now just to be sure. Hit by a cosmic ray I suppose?

I reported an issue because to me, assertion failure implies a logic error in the code and thus always a bug. Is that not the case here? Is predictable database corruption a reason to ungracefully abort and dump core?

laanwj commented at 11:45 am on June 10, 2015: member

Yes, it’s possible to trigger an assertion if a block is expected on disk but cannot be found. Normally this is a bug (block database and block storage out of sync) but it can also be caused by hardware or OS issues. The “cannot open” message indicates one of the blkXXXXX.dat gone missing (either temporarily or permanently).

welshjf commented at 1:26 pm on June 10, 2015: contributor

Alright. The level 1 check of all blocks was successful. I’ll upgrade to 0.11.0rc1 now, which I note adds more debug info for this error.

welshjf closed this on Jun 10, 2015

ripper234 commented at 2:40 pm on June 16, 2015: none

This reproduces for me on Windows 8 Bitcoin Core v0.10.2 Now I’m trying to launch bitcoin-qt and a few times and it just wouldn’t start.

Should the bug be reopened?
What info should I attach to help debug?

ripper234 commented at 2:57 pm on June 16, 2015: none

Followup:

My system is now in a state where bitcoin-qt isn’t running right now, and whenever I try to start it, it immediately crashes without any error message.

The splash screen shows

And the only error message is

Here is debug.log

ripper234 commented at 3:54 pm on June 16, 2015: none

FYI - Oddly enough, I had issues with another unrelated software (xmind mind mapper) refusing to open a file. I restarted my computer and both xmind and bitcoin-qt work now.

This means something in the global state of my computer/OS was bad, not just in bitcoin-qt.

laanwj added the label Data corruption on Feb 9, 2016

MarcoFalke locked this on Sep 8, 2021

Assertion `!“cannot load block from disk”’ failed #6263