I'm going to replace, lines 10776 and 10895 with some debug lines like you recommended before and then send you the output.

I also just installed Ubuntu 12.04 desktop x86_64 on my gaming rig (Steam linux here I come!), so I can test Armory there, too.

Hold off on that... I'll give you a version that has the blockchain-loading bug fix.

In fact, it's already committed. Try it.

Compiling now!

EDIT: No luck

Still got a seg fault. I can give you the crash report, but it doesn't look too helpful. Log output seems pretty useless, too.

Are you running it from the command line? Does it get through blockchain loading then crash? Mid-loading? I wonder if it's a wacky set of blkXXXX.dat files, which has turned out to cause issues in the past. But since those blk files are so damned big, I can never get anyone to send me one so I can debug it

Speaking of that, does it work in --offline mode?

If that works, sounds like a scan issue. I know it's a pain to redownload the blockchain... but if you are feeling generous with your time/bandwidth, could you rename your blk files and redownload and see if that solves it? If so, I can open the guest acct on my system for a night for you to scp the blk file with the problem. Not there yet, but I am getting frustrated by this...

This is definitely not a perfect release. But most of the issues are aesthetics in windows. The little "busy" icon does not even show up while the blockchain is loading. Windows XP was lightly tested, but I'm relying on you guys to help me with that one!

However, I think I quashed the bug causing crashes when new blocks come in while scanning. If you do experience the crash, just restart! (and then report it to me) I added a manual-entry window for "bitcoin:" URLs, in case Armory doesn't properly register itself with your OS (you'll see it on the send-BTC dialog). And I did some more polishing...

I'm going to replace, lines 10776 and 10895 with some debug lines like you recommended before and then send you the output.

I also just installed Ubuntu 12.04 desktop x86_64 on my gaming rig (Steam linux here I come!), so I can test Armory there, too.

Hold off on that... I'll give you a version that has the blockchain-loading bug fix.

In fact, it's already committed. Try it.

Compiling now!

EDIT: No luck

Still got a seg fault. I can give you the crash report, but it doesn't look too helpful. Log output seems pretty useless, too.

Are you running it from the command line? Does it get through blockchain loading then crash? Mid-loading? I wonder if it's a wacky set of blkXXXX.dat files, which has turned out to cause issues in the past. But since those blk files are so damned big, I can never get anyone to send me one so I can debug it

Speaking of that, does it work in --offline mode?

If that works, sounds like a scan issue. I know it's a pain to redownload the blockchain... but if you are feeling generous with your time/bandwidth, could you rename your blk files and redownload and see if that solves it? If so, I can open the guest acct on my system for a night for you to scp the blk file with the problem. Not there yet, but I am getting frustrated by this...

You know what? I bet there's a problem with one of your wallets. One of of them is corrupt, maybe?

Can you temporarily relocate your wallets out of the .armory directory and then reload? I bet it will start, then.

I'll try that in the morning. Although the wallets load fine (albeit single threaded) with the dev branch.

Oh! What about mempool.bin. It's possible for that to be corrupt, too.

Because that is such a common cause of crashing, I put logic into 0.84.1 to detect when Armory fails to load more than 3 times, and automatically delete mempool.bin. Even if that's not the problem, perhaps you can check for me that it is at least detecting it.

(1) There's a new entry in ArmorySettings.txt called "FailedLoadCount". That should be incrementing every time it crashes(2) The log file will eventually start reporting "<X> attempts to load blockchain failed. Removing mempool.bin." It should happen every time after the third failed load.

Can you at least check for me that it is doing that? Though, if it is doing that, then it is removing mempool.bin, and there's nothing more for you to try. So far...

You know what? I bet there's a problem with one of your wallets. One of of them is corrupt, maybe?

Can you temporarily relocate your wallets out of the .armory directory and then reload? I bet it will start, then.

I'll try that in the morning. Although the wallets load fine (albeit single threaded) with the dev branch.

Oh! What about mempool.bin. It's possible for that to be corrupt, too.

Because that is such a common cause of crashing, I put logic into 0.84.1 to detect when Armory fails to load more than 3 times, and automatically delete mempool.bin. Even if that's not the problem, perhaps you can check for me that it is at least detecting it.

(1) There's a new entry in ArmorySettings.txt called "FailedLoadCount". That should be incrementing every time it crashes(2) The log file will eventually start reporting "<X> attempts to load blockchain failed. Removing mempool.bin." It should happen every time after the third failed load.

Can you at least check for me that it is doing that? Though, if it is doing that, then it is removing mempool.bin, and there's nothing more for you to try. So far...

I moved my ~/Library/Application\ Support/Armory directory to a safe place and then reopened Armory and it worked! It started freaking out about losing the connection to the Satoshi client, but I think that's just because I opened armory right after waking up my laptop so I was ~50 blocks behind.

And it just crashed. I guess it must be one of my wallets. I'll load them one at a time and see what happens.

So I tried just renaming them *.wallet.off, but they all still loaded I'll just move them out of the folder.

Testing my offline wallet first.

EDIT: My offline wallets load, but my wallet that I imported from Satoshi (back when that was a thing) and my encrypted hot wallet both cause a segfault. I'm going to test them in Ubuntu.

Just a quick update... I'm on the absolute verge of the "real" release, with all the features completed for beta. The issue is that restoring paper backups and importing wallet files, sometimes causes Armory to hang, and I've spent my whole day trying to track it down. Unfortunately, it's not consistent, so I still haven't even been able to isolate where it's hanging.

On the upside, it hangs after it's done doing the wallet recovery scans, so it's okay once Armory is restarted. I just can't release beta like that...

When I do find it and fix it, I will go into "pencil's down" mode and focus on testing. A lot of testing. And I will need help.

Reposting the downloads for 0.84.1, because I'd still like people to help test that if they can. I don't know how long it will take to track down this wallet importing, but bugs found in 0.84.1 are still relevant to 0.84.2 and I can fix it before I release.

Or when you tried to actually broadcast it (you were able to broadcast it, it showed up on the ledger, but said it failed?)

this

Interesting... haven't seen that one before. Perhaps I just need to bump up the time that Armory that waits before declaring that it failed...

I have seen that once, when I broadcasted the tx before the Satoshi client had caught up. I should of course have reported it, but somehow felt it was only to be expected.

Oh, definitely evidence of my own testing bias... I wouldn't ever send a tx before satoshi is caught up, because I know in the back of my head what the result would be. This is why I need other people to test and find stuff like this

The newest version (which I'm still battling), detects when Bitcoin-Qt is still synchronizing, and pops up a warning. I should add to the warning that tx will not be broadcast right away, and perhaps add that same detection to the broadcast button to disable the message (or give a different one), when they do this.

Or when you tried to actually broadcast it (you were able to broadcast it, it showed up on the ledger, but said it failed?)

this

Interesting... haven't seen that one before. Perhaps I just need to bump up the time that Armory that waits before declaring that it failed...

I have seen that once, when I broadcasted the tx before the Satoshi client had caught up. I should of course have reported it, but somehow felt it was only to be expected.

Oh, definitely evidence of my own testing bias... I wouldn't ever send a tx before satoshi is caught up, because I know in the back of my head what the result would be. This is why I need other people to test and find stuff like this

The newest version (which I'm still battling), detects when Bitcoin-Qt is still synchronizing, and pops up a warning. I should add to the warning that tx will not be broadcast right away, and perhaps add that same detection to the broadcast button to disable the message (or give a different one), when they do this.

Mine got throught. I was *almost* fully sync'ed, it may have propagated once the client caught up, or it may have propagated immediately despite the error, I don't know. Before I had found the tx on blockchain.info, the client had caught up.

I'll put this behavior in the category of "undefined." There's actually a good chance it would go through, unless the transaction being spent was very recent. I could elaborate, but I don't think it's too important. I'll apply my same not-sync-detect logic to the sending of transactions to warn the user that they should wait until full synchronization before spending. It sounds like even if I don't get it right, this is an okay bug to have: tell the user it didn't work, but it actually did. Better than telling them it did work when it didn't, and the ensuing confusion...

Teaser: the beta testing version will be out very soon. I think I just finished the final feature, which is sometimes necessary for restoring very active wallets, both offline and online. This is mainly for people who are restoring offline wallets from paper backup, where the offline wallet was used more times than the keypool size (100-200). Since the wallet is offline it, has no way to know how many addresses were used, and will not recognize address 300 in its own wallet. The mechanism for resolving this has been haunting me for a while -- I want to make it possible for users to extend the keypool, but 98% of the time, they don't need to be bothered with this concept because Armory succeeds silently without input.

So, I have added it to the "Expert" interface, wallet properties now tells you how many addresses have been generated. You can click on it, and extend the address pool manually. If you think you used 1000 addresses in this wallet, put in 1,500 and it will extend the wallet for you. If you supply a number greater than 1000, it will warn you that computation may take a while (this is another reason to switch to the new BIP 32 wallets -- address "chaining" is much quicker).

As far as I can tell, all my multi-threaded features work -- offline-to-online, rescanning, importing, sweeping, wallet restore, wallet import, all in different modes, etc. I have to do a final testing pass on everything and then I will compile testing versions. I can't wait to finally get this thing out there!

It sounds like even if I don't get it right, this is an okay bug to have: tell the user it didn't work, but it actually did. Better than telling them it did work when it didn't, and the ensuing confusion...

I think this could cause some of its own problems, though. If you have a user that simply trusts what the software tells them (which would be 90% of the normal population if/when bitcoin/armory gets extremely popular, luckily it's much lower while bitcoin is a niche market) they may send coins again if it says that it failed, without even looking at the history or manually checking if it really did go through.

It may be a lower priority bug for the time being, but in the long run, it's something you would want to try to find if at all possible, in my opinion. But that's just my two cents.