Bitcoin core error opening block database

«Error opening block database» after regular startup. Works again once after each fresh install. #9454

Comments

Compunologist commented Jan 1, 2017

Happy New Year everybody!

Describe the issue

I have installed Bitcoin Core (64-bit) and changed the data directory to one on my NAS. I ran Bitcoin Core and after 2 days of synchronizing the Bitcoin Core window shows «Up to date». The program exits without any problems.

After each following regular startup however Bitcoin Core (64-bit) reports «Error opening block database. Do your want to rebuild the block database now?» and I have to abort the operation.

When I install Bitcoin Core again and choose to «Run Bitcoin Core (64-bit)» everything works again, including the already synchronized blocks.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Start Bitcoin Core
2. Message: «Error opening block database. Do your want to rebuild the block database now?»

1. Run the Bitcoin Core installer again: «bitcoin-0.13.1-win64-setup.exe»
2. Choose «Run Bitcoin Core (64-bit)», everything works again

What version of bitcoin-core are you using?

Bitcoin Core version v0.13.1 (64-bit)

Machine specs:

• OS: Windows 10 Pro
• CPU: Intel Core i7
• RAM: 8.00 GB
• Disk size: 256GB & 4TB
• Disk Type (HD/SDD): SSD & HD

Any extra information that might be useful in the debugging process.

This is how the debug.log looks like when the error occurs:
Bitcoin debug_not working on regular startup.txt

This is how the debug.log looks like after a reinstall with Bitcoin Core correctly running:
Bitcoin debug_working again after fresh install.txt

The text was updated successfully, but these errors were encountered:

Источник

Corruption: block checksum mismatch #11627

Comments

kollokollo commented Nov 7, 2017

Describe the issue

Bitcoin core runs normal, but when closing it, The WIndow appears (do not shut down the computer. ) and during this an Error message pops up.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. close bitcoin core
2. start bitcoin core and wait until everything is synchronized
3. klick on the close button of the bitcoin core window
4. error occurs

Expected behaviour

Bitcoin core should close without an error.

Actual behaviour

It seems that besides this error on cloning the application there is no other misbehaviour observed,

• RAM: 2GB
• Disk size: 1TB
• Disk Type (HD/SDD): HD, chainstate linked to SDD

Any extra information that might be useful in the debugging process.

[code]
2017-11-07 07:05:00 net thread exit
2017-11-07 07:05:00 scheduler thread interrupt
2017-11-07 07:05:00 Shutdown: In progress.
2017-11-07 07:05:00 msghand thread exit
2017-11-07 07:05:03 Dumped mempool: 0.009742s to copy, 1.33576s to dump
2017-11-07 07:05:04 Corruption: block checksum mismatch
2017-11-07 07:05:04 *** System error while flushing: Database corrupted
2017-11-07 07:05:13 Corruption: block checksum mismatch
2017-11-07 07:05:13 *** System error while flushing: Database corrupted
2017-11-07 07:05:15 Shutdown: done
[/code]

The misbehaviour started, after I have run bitcoun core on different (maybe old) wallets, causing a reindexing. I am now back in the original wallet which has not produced such error before.

The text was updated successfully, but these errors were encountered:

kollokollo commented Nov 7, 2017 •

BTW: Bitcoin core version v.0.15.0.0-g3751912e8e
and dmesg shows nothing special related to the Harddisk or the SSD. (no file system errors)

fanquake commented Nov 8, 2017

How old were the «old» wallets?
Does the crash only happen on an exit during syncing, or after it has completed?
Does the corruption disappear if you revert to using a newer wallet?

TheBlueMatt commented Nov 8, 2017

This isn’t a wallet error, its a data-read error which indicates either your disk is silently corrupting data (which can happen without filesystem errors) or your memory is bad/unstable or your CPU is too host/unstable/overclocked. Most common is memory errors or unstable CPU — run memtest and check the temperature of your CPUs under load (eg via linpack or similar load/performance tests)

kollokollo commented Nov 8, 2017

The old wallets were 2011 and 2014. The problem started when I reverted back to the 2017 wallet and is now persistant.
The Error only appears on an exit. Until then, Bitcoin core runs normally. It appears everytime now on exit. The corruption has not disappeared (using the new wallet now again).

The Computer (its a laptop) has never been shut down without having closed bitcoin core. The wallets were exchanged always when bitcoin core was not running.
The Harddisk nor the SSD (which I use for the chainstate folder) have reported errors. The Laptop is a recent model, I never saw RAM problems. To verify if it was a read error: Which file should I read to test and what against should I compare the content?

kollokollo commented Nov 8, 2017 •

BTW: Syncing was complete when the error appeared. The Laptop is an ideapad 110S, max 1 year old, not modified/overclocked or so. Temperature under load was not noticable, however the (external) SSD for the chainstate got quite hot.

kollokollo commented Nov 8, 2017 •

Here is another symptom: Everytime now bitcoin core is restarted, it starts syncing from Mo, Nov6 8:45, al though the syncing had completed before. If this persists, this would make bitcoin core unusable with time (with the corrupted data).

kollokollo commented Nov 9, 2017 •

Today I got the following error, during synchronization:
[code]
o) warning=’1 of last 100 blocks have unexpected version’
2017-11-09 07:52:48 UpdateTip: new best=00000000000000000093ed958fcdee0e7025d7b8d8f15fed221e4c4da32d0369 height=493686 version=0x20000000 log2_work=87.438028 tx=269732432 date=’2017-11-08 23:51:00′ progress=0.999668 cache=224.6MiB(1705500txo) warning=’1 of last 100 blocks have unexpected version’
2017-11-09 07:52:50 LevelDB read failure: Corruption: block checksum mismatch
2017-11-09 07:52:50 Corruption: block checksum mismatch
2017-11-09 07:53:17 Error reading from database: Database corrupted
[/code]

Bitcoin-qt then stopped working (windo not responding anymore). After a while it core-dumped (At least I got the message, that the app has crashed and there is not enough memory to save the core and inform the developpers).
With the next start, the problem persisted (again not responding) and I had to kill the process with -9. .

No IO-Errors in dmesg.

So If this problem is not caused by a bug in bitcoin-qt, how can one fix the database?

Источник

«Error opening block database» on new installation on Windows 8 when using custom database directory #6200

Comments

fresheneesz commented May 28, 2015

I have 3 hard drives — one internal, two external. Creating a custom data directory works on 2 of my drives (the internal, and one external), but doesn’t work on my third hard drive. The problem is, I don’t have space to store the 50GB+ blockchain on the two drives it works on. The one it doesn’t work on is a terrabyte drive — bitcoin’s window acknowledges there’s 600GB of free space on it.

But when I write a path on that drive, and press ok, it creates what look to be the correct file structure, but opens with an error message saying:

I can abort, or press ok. If i press ok it says «Error opening block database» and quits. Dick.. How can I debug what’s going on here?

The text was updated successfully, but these errors were encountered:

fresheneesz commented May 28, 2015

laanwj commented May 29, 2015

What file systems are involved?

fresheneesz commented May 29, 2015

Oh huh. The ones that work are NTFS, the one that doesn’t work is exFAT — I guess that’s too much of a coincidence to discount. I would expect, tho, that filesystems are abstracted by the OS so the program doesn’t have to care about it, no?

Diapolo commented May 30, 2015

Is there any more info in the debug.log? Maybe you can paste that, so we can take a look? Any special things in bitcoin.conf or passed to the executable via parameters?

Edit: And perhaps most important, which version it it ;)?

fresheneesz commented May 30, 2015

I was trying Bitcoin Core version v0.9.3.0-g40d2041-beta, now I’m trying v0.10.2, same issue. My debug.log contains:

And my db.log exists but is empty. I haven’t modified bitcoin.conf — I didn’t do anything other than install and run the program this time round. I don’t know where to find bitcoin.conf either — I don’t see it in the install directory nor the data directory.

fresheneesz commented May 30, 2015

I ran chkdsk, and that solved it : ) . The bitcoin client should have printed that error in its GUI tho. Can we keep this ticket open until the error is displayed to the user via the GUI?

Diapolo commented May 31, 2015

Great you fixed it and yeah it seems the DB init flow doesn’t handle this correctly. @sipa can you have a look?

laanwj commented Jun 1, 2015

The generic message should be extended to mention that one should check the debug log for more details about the errors. This is too rare a condition to implement specific logic for, or add specific translation messages, IMO.

fresheneesz commented Jun 1, 2015

@laanwj How exactly do you know how rare this is? This literally came up for me twice in a row (in the same day after I ran a chkdsk, I had to do it again later that day). Also it shouldn’t matter how rare this specific case is, because I’m sure there are a wide variety of cases where a message is written to the debug log that should find its way to a user-facing error message in the GUI.

Also, please don’t simply close tickets without allowing people to discuss your opinion.

theuni commented Jun 1, 2015

@fresheneesz I’m going to guess that this drive is using write-caching and isn’t being unmounted properly (pulled the plug/power without safely removing). Are either of those correct?

fresheneesz commented Jun 1, 2015

Dunno about write caching, but yes indeed the issue is likely the power being turned off without safely removing the drive. Assuming most people are safely removing their drives isn’t a safe assumption. (See what I did there ; )

theuni commented Jun 1, 2015

Sorry, but that logic just doesn’t follow. If write-caching is enabled and you’re unplugging the drive suddenly, all bets are off. You have essentially just unplugged a mounted (and busy) internal hard-drive. In fact, last I used Windows, it would even pop up and say «drive not ejected cleanly, corruption may have occured» or something. If that’s the case, there’s little that can be done here.

If write-caching is disabled, unplugging «should be» safe, but I should think it would also be horrendously slow.

fresheneesz commented Jun 1, 2015

You mean the logic of «most people don’t give a shit what their computer wants them to do» doesn’t sound like truth to you? Why is it unreasonable to expect Armory to tell me «Hey, run a chkdsk on drive E please» ?

theuni commented Jun 1, 2015

And then, suddenly, they care what the computer wants them to do?

Computer: Hey, don’t unplug that, it won’t end well.
User: I’ll unplug it anyway.
Computer: Hey, you shouldn’t have unplugged that.

Computer: Error opening block database. Hey, run a chkdsk on drive E please.
User: Dammit computer, what do you want from me?!

The fact that leveldb spits out an error that says «run chkdsk» might mean that we can detect that specific case and present it to the user. But in nearly every case I can think of where we would show that, the more correct response would be «something’s dangerously wrong with your setup».

fresheneesz commented Jun 2, 2015

@theuni Most people only care when it immediately affects them. Plus your computer isn’t very vocal about its desire for you to disconnect things safely. But if your program says «hey you can’t use me until you do this» people will do it. So yes, «suddenly» they care. I’d appreciate less sarcasm.

But in nearly every case I can think of where we would show that, the more correct response would be «something’s dangerously wrong with your setup».

And what should users do if they run into some «database can’t be loaded error» and their setup is «dangerously wrong»? Just give up and never use Armory again? I don’t understand why you think a more understandable error message is unreasonable.

What are these cases you can think of where the correct response would be «your setup sucks and we won’t help you fix it»?

theuni commented Jun 2, 2015

Ok, the bickering is getting us nowhere. On to the code:

We don’t get any useful info out of leveldb other than a failed open and an error message.. nothing to test against. We don’t know what failed or why. Advice to run chkdsk could possibly end up being wrong (and harmful) more often than not.

So the only solution here, other than «do nothing» is to print the leveldb error verbatim to the user as well as to the log. In this case, it’d be a popup saying «IO error: WinMmapFile.Append::UnmapCurrentRegion or MapNewRegion: : The operation could not be completed because the volume is dirty. Please run chkdsk and try again»

As @laanwj said, this is a rare edge-case. The question to ask is «would showing the user that info directly result in more or less confusion overall».

fresheneesz commented Jun 2, 2015

I’ve seen no evidence that this edge case is at all rare. That really sounds like an unsubstantiated claim. We do want your average non-techie to be able to use Armory, right?

Anyways, printing out the leveldb error verbatim sounds like a perfectly fine solution to me. As long as errors aren’t pages long, people read em, and if the solution to the problem is written right there in the error (like it seems to be in this case) then great!

Источник