Topic: Can't dl blockchain - 'fatal internal error' then segfault - page 2. (Read 2850 times)

Hi all, just to keep you updated... I still haven't managed to sync up the blockchain completely. The client does seem to keep crashing out sometimes. Half the time it says 'a fatal internal error occurred' and shuts down nicely, the other half it just quits and I see a core dump.

Removing the last, incomplete blk00xxx.dat at least allows it to restart, but I notice it always insists on reindexing from the beginning, even when I leave all the rev00xxx.dats alone. But at least I don't have to keep redownloading the blockchain-so-far so that's something.

Anyway I seem to be okay up to blk00133.dat, apparently that's up to "2 years and 24 weeks behind" so we shall see. But it's still in the process of reindexing all that.

I think that you need to delete the latest blk....dat files, latest rev.....dat files, and the latest .ldb files in blocks/index. However, I'm not very sure about this. You might want to check this with someone else.

Okay trying that. It's only early days yet (~block #46000) but it hasn't crashed yet.

A more general question: if I do somehow end up with a big blockchain that's mostly correct until the last little bit gets corrupted, what exactly would I have to delete to 'roll it back'? I get that I'd have to delete the last blk00xxx.dat, but what other files? I'd hate to have 19GB of perfect blockchain data and have it redownload every damn thing from the beginning.

you can try -connect=191.236.50.217 to connect only to my node and download from there. You might want to delete existing block data prior to doing this to clear any bad block data from before.

Well, just to give an update... bitcoin-qt is still running, it hasn't crashed... but I don't like what it IS doing. Basically block downloading stalled 40 min ago, as shown by the timestamps for blk00006.dat and rev00006.dat. It has been stuck at block #156748 all this time. What IS being continually updated is debug.log, which is now almost 900MB!!

The last few lines of debug.log now are:

2015-06-03 21:50:46 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-03 21:50:46 Misbehaving: 83.85.132.142:8333 (329801600 -> 329801700)
2015-06-03 21:50:46 ERROR: ConnectTip() : ConnectBlock 0000000000000088dc6197ddd62a76882d4d6ec4ea619e79d51fdecab423c71d failed
2015-06-03 21:50:46 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-03 21:50:46 Misbehaving: 83.85.132.142:8333 (329801700 -> 329801800)
2015-06-03 21:50:46 ERROR: ConnectTip() : ConnectBlock 0000000000000088dc6197ddd62a76882d4d6ec4ea619e79d51fdecab423c71d failed


I presume that most of the 900MB is like that. Core is also telling me that there are 10 active connections to the network which sounds like *that* isn't the problem.

GRR!   If it doesn't like the last few blocks for some reason, why the hell can't it just go back to whenever it DID like them and restart the download from there? And how about trimming debug.log while you're at it?

ETA: hmm wait a minute... are those lines telling me that it's being fed bad data by some peer? But if so, why doesn't it just try someone else?

It's probably because of the predefined settings.
Can you try to change datadir of blockchain?

something like that; "./bitcoin -datadir=/somewhereElse/ "

Those lines of the debug.log are for the synchronization of the blockchain.

I'm not sure what is happening, it could be bad memory, maybe run a memory check on the laptop?

Machine is a 5-yr old laptop with 3GB of memory. Bitcoin version and installation as above.

I'm now getting different behaviour that may be more acceptable. In my most recent run, it crashed out thus:

The last few lines of debug.log are all of the form:

2015-06-03 20:50:19 UpdateTip: new best=0000000000000778dfa81c3a653acf1ef06ce13da4747cde8529cc4fe86a81a6  height=138839  log2_work=65.787511  tx=1169347  date=2011-07-30 19:22:59 progress=0.007195  cache=171211
2015-06-03 20:50:19 UpdateTip: new best=00000000000007fadd5d4e5e0210a8bbfd4eca94af0bb2b63de6898e56c7f983  height=138840  log2_work=65.787675  tx=1169378  date=2011-07-30 19:37:30 progress=0.007195  cache=171228

... for hundreds of lines

This time Bitcoin-qt never even showed me a dialog box telling me it encountered an error. It simply crashed out. I'd invoked it from a terminal window and on crashing I see the following in the terminal:

*** glibc detected *** bitcoin-qt: double free or corruption (out): 0x2b308d40 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x74f82)[0x2a61f82]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0x96fc51f]
bitcoin-qt(+0x291f0f)[0x5c8f0f]
bitcoin-qt(+0x28eff9)[0x5c5ff9]

... followed by several similar lines and then a 'memory map', however that helps.

HOWEVER, I have now restarted bitcoin-qt, and after a while it just resumes the synchronisation. So with a bit of luck it will simply carry on with no further crashing.
Do you reckon it's dodgy memory? It looks like dodgy memory to me.

What version of Bitcoin Core are you running? Are you compiling from source? Also, what are the specs of your machine? Can you post the debug.log here? All of these will help us diagnose the issue.

Hi all. Though I use electrum for all my wallet needs, I use bitcoin-qt to have a local copy of the blockchain. A few days ago it told me something about a need to reindex, or a corrupt database, or something... can't remember.

Anyway since then I have repeatedly tried to download the blockchain from scratch and it cannot proceed past four years ago. I have now completely removed and reinstalled bitcoin-qt running under Ubuntu-12.04, and I still get the same problem. I try downloading from scratch, it goes okay until I get to about 4 years out-of-sync. Then bitcoin-qt tells me there was a fatal internal error. Trying to run it subsequently it keeps mentioning a segmentation fault. All I can do is delete the whole of ~/.bitcoin and... round we go again.

Any ideas? There's still 60GB of space on the hd partition.

ETA: in case it's important, the software tells me it's "Bitcoin Core version v0.10.1.0-gd8ac901 (32-bit)" and I installed it using the standard Ubuntu apt-get way of doing things.