BitcoinArmory

BitcoinArmory copied to clipboard

Sorry for my previous 2 issues, I forgot to re-build the project.

Now I got a real one. After starting, Armory started scanning the transaction history. For some reason it stopped at 96% and when it hung there for a while I noticed that python was taking up 100% of its CPU thread. That's now already for 5-10 minutes, so I think it will last indefinitely, I will restart in a second if it persists.

This is how it looks like: http://screencloud.net/v/CMo4

I don't see a problem in the log file: https://gist.github.com/stevenroose/6bef26278802ee2d6fd4

Btw, just a question, is the transaction checking sequential or parallel? I noticed that now it takes only 1 thread on my CPU, so I'd guess it's sequential. Can't this check be done in a parallel way?

After a restart, it behaves exactly the same. It's not because of lack of RAM. I have the Armory directory on a USB stick (to which nothing has been written during scanning...), that has sufficient space available.

Are there any other resources I can provide?

Gah, I don't know why people keep having this problem -- and most importantly, I can't replicate it.

You can run Armory from the command line and see the output from the C++ code. I bet you're going to get a bunch of orphan block messages. The only way I know to resolve this is to redownload the blockchain.

Luckily, my persistent blockchain stuff will fix this. Hopefully will have it in a few weeks. It won't even touch the blk*.dat files anymore. It's the source of a lot of problems... My guess is that somehow those files are being corrupted or something. I couldn't tell you for sure, since I've never had the problem.

If you let Armory re-sync for you, it will run Bitcoind with the -dbcache option which speeds up download by like a factor of 2. If you're running it yourself, run Bitcoin-Qt/bitcoind with -dbcache=1000. But just the first time, during initial download.

Here is the ArmoryQt.py output: https://gist.github.com/stevenroose/4cfe4402e9c44304ef97

There is one Python error between the reading of blkxxxx.dat files and then indeed a lot of orphan messages. Because I thought the rapid stream of those lines would delete the others, I interrupted the program, I'll write it to a file now to see what comes after those messages.

Ok, there just stay flowing out those same orphan messages ***ERROR: Block previously main branch, now orphan!?<block hash>

Very strange...

Yup, that's the error. Somehow it skips a block when scanning and then thinks the rest are orphans. As I said ,I don't know why that happens, but it is resolved by re-downloading the blockchain.

Is it possible that the recent change in database infrastructure is the cause of this problem? The release (0.8.0) was in February 19th, so that must be somewhere around block 223,378...

I am currently having this issue. If I wait long enough, Armory finishes syncing and shows my balance, but the orphaned block errors will recur and freeze the UI for a long time. (Also, due to another bug, anytime Armory gets out of sync with the block chain, it segfaults, so this freeze makes that crash inevitable as eventually a block comes while it's frozen). This is completely unusable. I have no interest in re-downloading the block chain since that will not fix the bug. I am willing to send you my blockchain or give you access to it, so you can reproduce and debug this issue.

The problem will be going away with the "persistent blockchain" update, which will actually not use the blk*.dat files at all. It will retrieve the data directly from Bitcoin-Qt/bitcoind (via local socket). I am curious what is causing that problem, but I feel like spending time to figure it out (and deal with blk file transfers) may not be the best use of my time.

Is this update released yet?