Extremely long engine initialization, v 0.95.1

[Coiner.de]

Then you should consider finding a list of strong well known nodes (explorers, miners, high speed ones) and add them to your bitcoin.conf by IP just to finish bootstrapping.

How do I find those?

https://bitnodes.21.co/nodes/leaderboard/ should be helpful.

[1715700218]

1715700218

[1715700218]

1715700218

[ToF]

Thanks everyone for the help! I was able to finally get the BTC database synchronized. Bitcoin Core is working. Unfortunately, Armory is not. After armoryDB.exe opens its command prompt window, Armory crashes with error "tried to use invalid lmdb iterator".

At first there was a problem with database version mismatch so I deleted the "databases" folder under Armory, then the new error happened. Any suggestions? I will post the log in a short while if I can save it before Armory crashes.

[ToF]

Update: It seems to be building the database now, I restarted Armory 3 times, each time a different problem with armoryDB.exe, but now it's building so it looks OK. Quite sensitive though...

[goatpig]

Armory's db is matched to the copy of the blockchain it was built upon. You cannot split the 2. This means in your case you should rebuild your DB from scratch.

[ToF]

That's what I am doing - the databases folder was deleted so Armory is building it from scratch. It seems to be working OK now, in 12 minutes the database should be built it says.

[ToF]

Hmm... armoryDB.exe is just crashing now right after headers scan. Any idea? The error right before the crash seem to be always somewhat different.

[ToF]

The Errors recorded in log before the crash look like:

-ERROR - 1447113712: (..\lmdb_wrapper.cpp:152) Returning dirty key ref

Log file opened at 1480059815: X:\Other\BTC\Armory\armorycpplog.txt
-ERROR - 1480060049: (..\SocketObject.cpp:438) POLLERR error in readAndWrite

[goatpig]

Create a fresh db folder, run armorydb against that with --db-type=DB_BARE --ram-usage=1. Once it's done building, start the client and let it scan.

[ToF]

OK, will do. Just to clarify - the database folder I should delete is under "Armory\databases", correct?

[goatpig]

Given your custom folders, it should be:

X:\Other\BTC\Armory\databases

You don't have to use that folder, you can point to another one using the --dbdir command line argument as well.

[ToF]

I tried running this command:

armorydb.exe --db-type=DB_BARE --ram-usage=1 -–satoshi-datadir="X:\Other\BTC\Bitcoin" --datadir="X:\Other\BTC\Armory"

but it seems there is a syntax error with the -–satoshi-datadir="X:\Other\BTC\Bitcoin" part but I just can't see it.

[goatpig]

-–satoshi-datadir="X:\Other\BTC\Bitcoin"

That second prefix dash looks weird. It should be 2 minus (-) signs.

[ToF]

OK, thank you for spotting that! Not sure how it got there. However, the DB creating did not finish I am afraid. It stopped at this error:

-DEBUG - 1480128093: (..\Blockchain.cpp:242) Organizing chain
-INFO  - 1480128131: (..\DatabaseBuilder.cpp:56) updated HEADERS db in 2484.12s
-INFO  - 1480128131: (..\BlockUtils.cpp:1636) Enabling zero-conf tracking
-ERROR - 1480128133: (..\BDM_mainthread.cpp:257) caught exception in main thread: no sdbi at this key

[goatpig]

Somehow, your system appears to be very unstable. This isn't the first time you report errors that can be summed up to LMDB failing entire sets of I/O operations.

I would suggest you try to sanitize and isolate your setup as much as you can. This is what I would do:

1) Uninstall Armory, make sure the binaries are gone, download 0.95.1, verify the hash and signature, then install fresh. You don't need to wipe your datadir for that purpose, only the installation folder.

2) Do not run BitcoinQt when Armory is performing it's original build & scan. This should free up a lot of resources. Maybe taxing your system puts it over in terms of stability. You can start BitcoinQt once Armory is fully built and scan.

Running the DB alone gets you through the build phase. You have to run a client against that DB at least once so it has some wallet data to scan the blockchain against.

Your steps would be:

a) Start DB alone, let it complete. Once it says "Enabling zero-conf tracking", it's ready.
b) Start the client, you will know within the client when the scan is complete.
c) Start BitcoinQt.

3) Do not build the DB on your NAS. Create a folder on your SSD, and point to it specifically with --dbdir. The final DB_BARE db is ~200MB, DB_FULL is ~1GB, you shouldn't have trouble affording the space.

4) Consider running a few benchmarks on your system to test for stability. At least one RAM, one CPU and one storage stress test.

5) If you find out your CPU isn't stable underload, you can use --thread-count to manually force the level of parallelism during build & scan operations. This defaults to maximum available cores in your system.

[ToF]

I believe the PC is actually very stable, I have not experienced a similar issue before. But now it seems it has finished building the database, well maybe.

In the command prompt window i know see this:

-INFO  - 1480142143: (..\DatabaseBuilder.cpp:268) parsed block file #688
-INFO  - 1480142189: (..\DatabaseBuilder.cpp:268) parsed block file #689
-DEBUG - 1480142189: (..\Blockchain.cpp:242) Organizing chain
-INFO  - 1480142227: (..\DatabaseBuilder.cpp:56) updated HEADERS db in 2603.85s
-INFO  - 1480142227: (..\BlockUtils.cpp:1636) Enabling zero-conf tracking


That is the last line I see in there and it does not update. There is no error recorded either though so I suppose it finished? The Armory database has 142MB.

It was all so simple last year...

[goatpig]

DB is done building. You have to start the client to scan it now.

I believe the PC is actually very stable, I have not experienced a similar issue before.

People are having issues with upgrading to 0.95 because they do not wipe out the existing DB or use a different dbdir.

The issues you are experiencing are in a whole different class, and you are the only one with these. Surely if this was an in issue with the code, it would have manifested itself several times since April of this year, when 0.94 came out.

[ToF]

People are having issues with upgrading to 0.95 because they do not wipe out the existing DB or use a different dbdir.

The issues you are experiencing are in a whole different class, and you are the only one with these. Surely if this was an in issue with the code, it would have manifested itself several times since April of this year, when 0.94 came out.

I am not sure if I am the only person with such problems, though I may be the only person who reported it at the forums but that's a different thing. I am not sure what caused these issues but the PC is actually an extremely stable machine running Windows 7 which I restart only about once a month. There is definitely no malware etc.

The last time I used Armory was the 0.93.x version several months ago and I did not experience any of the issues at all. Of course, there can always be another application or previous installation interfering.

Hopefully it will work in the end.

[ToF]

Unfortunately, no luck. Armory still crashes at the ArmoryDB.exe part. These are the last records in dbLog.txt:

-ERROR - 1480209973: (..\lmdb_wrapper.cpp:1435) Headers DB has no block at height: 0
-ERROR - 1480209973: (..\lmdb_wrapper.cpp:1415) No headers at height 0

Before the command prompt window crashed I also saw error about missing key pairs as before. The PC is really stable, I don't think that's the issue. Perhaps something is left from the old version installation somewhere still?

[goatpig]

Unfortunately, no luck. Armory still crashes at the ArmoryDB.exe part. These are the last records in dbLog.txt:

-ERROR - 1480209973: (..\lmdb_wrapper.cpp:1435) Headers DB has no block at height: 0
-ERROR - 1480209973: (..\lmdb_wrapper.cpp:1415) No headers at height 0

Before the command prompt window crashed I also saw error about missing key pairs as before.

These types of errors have 4 different causes:

1) You are running a same DB folder against different blockchain folders.
2) You are running different versions of the code against the same DB folder. You should get an error output in the console and GUI in this case.
3) You have a bad/corrupted copy of the blockchain.
4) Your machine is unstable.

The PC is really stable

There is no knowing that without passing an hour worth of memtest and prime95 without errors. If you can actually pass these tests, then consider 3).

Perhaps something is left from the old version installation somewhere still?

The DB code does not use shared libraries, it's all in the one binary. The only possible "left over issue" is using a DB dataset built with a previous version (i.e. 0.94 data vs 0.95 binary).

[ToF]

I have just left prime95 running the Blend test for over 2 hours, no problems at all.