Scanning transaction history hangs at 96%, python 100% CPU

[stevenroose]

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?

[stevenroose]

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?

[etotheipi]

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.

[stevenroose]

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.

[stevenroose]

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

Very strange...

[etotheipi]

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.

[stevenroose]

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

[tril0byte]

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.

[etotheipi]

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.

[stevenroose]

Is this update released yet?