1) Please don't hijack somebody else's thread, create your own and post your log files.

2) There is a difference between allocated memory (malloc) and mapped files (mmap). The usage figures show you total RAM load, but the distinction is significant: allocated memory belongs to the process while mapped files boils down to hinting the OS that you want these files cached in RAM for faster access. Mapped memory does not prevent new allocations, it simply uses otherwise free resources to speed up I/O.

You are better off documenting yourself on these topics than just jumping to conclusion. Armory has been using this model for nearly 3 years now.

3) This is an open source project, feel free to submit code if you have a better solution, or at least participate to the testing phases and provide constructive feedback and bug tracking.

The DB does not use shared libraries, you should be able to just move the binary around and get it to run.

DB is full cpp code. There is no install process to just install the DB, but you can only build that if you wish so, by running

Apparently I messed up.

Here is the code checking the folder attributes:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1109

and here is the underlying call:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/DBUtils.cpp#L285

Basically this:


Should be:


However, if you chmod your symlink to 777 and it still doesn't work, it may be that access(2) doesn't play well with symlinks altogether. You have a few solutions to try.

First, you should set the 4 to a 2, build and try again. If that fails, comment out the path test line entirely and try again. This is just the code testing that the folder exists, for sanity checks. Lastly, if that still fails, try to point the DB directly to that HDD's path.

Delete your databases folder. Run Armory with this added command line argument:

--db-type=DB_BARE

Post armorylog.txt and dbLog.txt

I going to tie Armory client shutdown to ArmoryDB's shutdown when the client spawns it. The distinction at startup is too wide to simplify it to just that.

Let's take it from the top then.

1) Are you balances right?

2) How many wallets are loaded?

3) Is history missing each wallet's properties dialog?

4) I need to see armorylog.txt and dbLog.txt

I'm not aware of any changes in BU that would break compatibility with Armory atm, although I don't follow its development.

There are plenty of messed up scenarios where the client fails to close bitcoind in automated mode. I'm moving that functionality to the DB and rewriting it in the process for the next version. That should side step all the corner cases.

Works on Wheezy, no reason it won't on Jessie.

You are saying you only have history for the last few days?

I don't understand what you are trying to say, can you elaborate?

Let's see dbLog.txt

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.


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).


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).

You are fine. You will need to upgrade when 0.96 comes out if you want sign SW transactions. If you do not create try to spend SW outputs, you won't need to upgrade.

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


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.

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.

All of these are known issues.

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