Topic: Upgraded to 0.96 building database takes long (Read 1674 times)

All is clear thanks again

It means it does not maintain the dataset to resolve arbitrary tx hashes. On the GUI side that means you can't input tx nor fee of incoming transactions (people paying you). This is the state 0.94 was in.


Well yes and no. You can keep on using this DB type but due to a mess up on my end, you have to specify the --db-type on each run. I fixed that issue but there's no build out with it yet. You're not supposed to be able to swap types once a DB is instantiated, but again, I messed up the check.

If you don't specify it, it will corrupt the DB on the next run. You can use armoryqt.conf to force that arg for now. Once the fix goes into the next build, you won't have to worry about the arg after bootstrapping.


I can't tell. Clearly there is an issue that only exists with slow/old machines, since I never run into it, and all cases I can remember like yours are on old/weak machines. For now there seems to be a critical point at which a machine is too aged/weak and can't bootstrap the DB off of defaults. Until the point I figure out what's going on, you are stuck with using custom settings. What you ran is basically the fail safe setting.

I don't think the issue is related to block size but rather block load. Smaller blocks with lighter transactions (up around block #350k) are easy enough to parse. It's the recent stuff that's grinding some machines to a halt. Seeing you eventually got past it, I'm gonna guess your machine can keep on going.


False positives. A bunch of debug verbose I left there cause people on OSX are complaining about slow shutdowns. This helps me figure out what's going on. Ignore on anything but OSX.

It works! Thanks so much for the help!  

I tried to look up what DB_BARE means and I think it means I'm still a fill node (through bitcoin core) and everything is validated fully but some hash information is not stored making it some searches from Armory less rich. Is that correct? Can I just keep running like this?

Considering the difficulty I had with getting this to run does that mean relatively soon I won't be able to run Armory online on this computer or shouldn't I worry about that?


Edit:

When I close the client I see the following errors in the log (and it takes a while to close the client meanwhile it's not responding). Is that all ok?

Yes.

That works but it's done quite fast:


I ran it like: ArmoryDB.exe --datadir="XXX\Armory" --satoshi-datadir="XXX\Bitcoin" --db-type=DB_BARE --ram-usage=1 --thread-count=3

Next start the client?

Start the DB manually. Ignore the client for now.

It shows this pop-up:



But dblog.txt doesn't show anything. In Armorylog.txt I found:

2017-07-08 14:11:50 (ERROR) -- ArmoryQt.py:1819 - Failed to start Armory database: cannot concatenate 'str' and 'int' objects
Traceback (most recent call last):
  File "ArmoryQt.py", line 1797, in startArmoryDBIfNecessary
  File "SDM.pyc", line 392, in spawnDB
TypeError: cannot concatenate 'str' and 'int' objects

Try with --ram-usage=1 --thread-count=3. No need to wipe the DB this time.

Yes and yes.

I didn't build it but downloaded the 0.96.0.4 release from github.

If you mean whether I'm starting Armory with --db-type==DB_BARE as a command line argument, no I'm not. Should I try that? Do I need to delete the database folder again?

Are you building with --db-type==DB_BARE?

This is with 0.96.0.4?

At this point it's probably still failing. Delete dbLog.txt and your databases folder, then start from scratch and post the log.


Legacy from the older versions. I'll fix that one of these days. All versions I've put out are x64 indeed.

Ok, I tried the latest #4 testing build last night until this morning. It ran for 12 hours and got to 4% (1.5 months left) and slowed my PC down to a very slow pace like before and was consuming most of the memory.

Does this mean the bug is still there or should I just let it run for >24 hours (or much more?)

BTW: I saw that the Armory installer is installing into "program files (x86)" folder by default while it's a 64 bit application. Is that correct?

Ok thanks for all the help so far.

I found 2 more lines in my log that might help so I'm going to leave them here:

Not when it triggers this issue.



I don't know that they are related yet.


Once it's ready and tested. Can't tell you more.

Ok, so if I leave it running like this it will never finish?

Does this also have something to do with the weird big that started all this? (The, non-existing (?) outgoing transaction that Armory showed with the associated lower balance)

When are you planning to release the testing build? (I have to travel in a few days).

No that means you synced your chain with a super old version of Core and never had to nuke it since. Nothing wrong with that, but the size of the early block files is a tell.


No this means your computer is so weak that you can 100% trigger this issue even on top of a completed build. I've got a VM gimped enough that I ran in the issue every other 5 scans now (I've never managed to reproduce the issue before), so I think I can get it under control. You'll have to wait for testing build with the fix or build it yourself once I push.

Okay, is having an old copy a problem? I always run a bit behind for security reasons (want to give it some time in the wild for bugs to be found). Version 0.13 is only 10 months old. Or is this because my blockchain is based on even older versions of Bitcoin and upgraded every time?

Meanwhile I started ArmoryQT by itself. I blazed passed the first steps (organizing chain, building database) and again is hanging my computer while scanning transaction history. Anything I can see or do?

Edit:

ArmoryDB memory usage is 3.6GB. Total memory usage is 93-99% ArmoryQT UI is hanging (like always, the little spinning banner is frozen)

Edit2:

Memory usage dropped to 1.4GB, 67% of total system memory usage.

You have an old copy of the chain, that explains it. Just start Armory the regular way now, see how that goes.