Armory - Discussion Thread

[Red Emerald]

I'm still getting a segfault on OSX

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.

[1714220190]

1714220190

[etotheipi]

I'm still getting a segfault on OSX

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

[etotheipi]

New testing release:  Armory 0.84.1-almost-beta

Ubuntu/Debian 64-bit (*.deb)
Windows 64-bit (*.msi)
Windows 32-bit (*.msi)

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

Please try it!

[Red Emerald]

I'm still getting a segfault on OSX

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

It happens right after the blockchain finishes scanning.

This log might be helpful.

Code:

Crashed Thread:  2

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 000000010dcc2000-000000010dcc3000 [    4K] r-x/rwx SM=COW  /Users/USER/*

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8a055686 mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fff8a054c42 mach_msg + 70
2   com.apple.CoreFoundation      	0x00007fff819cc803 __CFRunLoopServiceMachPort + 195
3   com.apple.CoreFoundation      	0x00007fff819d1ee6 __CFRunLoopRun + 1078
4   com.apple.CoreFoundation      	0x00007fff819d16b2 CFRunLoopRunSpecific + 290
5   com.apple.HIToolbox           	0x00007fff865d40a4 RunCurrentEventLoopInMode + 209
6   com.apple.HIToolbox           	0x00007fff865d3e42 ReceiveNextEventCommon + 356
7   com.apple.HIToolbox           	0x00007fff865d3cd3 BlockUntilNextEventMatchingListInMode + 62
8   com.apple.AppKit              	0x00007fff827df613 _DPSNextEvent + 685
9   com.apple.AppKit              	0x00007fff827deed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
10  com.apple.AppKit              	0x00007fff827d6283 -[NSApplication run] + 517
11  QtGui                         	0x000000010f4f250b QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 1259
12  QtCore                        	0x000000010e8b9ba5 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 501
13  QtCore                        	0x000000010e8bca8e QCoreApplication::exec() + 206
14  QtGui.so                      	0x000000010eecb971 meth_QApplication_exec_ + 81
15  org.python.python             	0x000000010dce25a9 PyEval_EvalFrameEx + 9244
16  org.python.python             	0x000000010dce0147 PyEval_EvalCodeEx + 1934
17  org.python.python             	0x000000010dcdf9b3 PyEval_EvalCode + 54
18  org.python.python             	0x000000010dd1bc70 0x10dcc9000 + 339056
19  org.python.python             	0x000000010dd1bd3c PyRun_FileExFlags + 165
20  org.python.python             	0x000000010dd1b726 PyRun_SimpleFileExFlags + 410
21  org.python.python             	0x000000010dd3fe27 Py_Main + 2715
22  libdyld.dylib                 	0x00007fff8621c7e1 start + 1

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff8a057d16 kevent + 10
1   libdispatch.dylib             	0x00007fff81f35dea _dispatch_mgr_invoke + 883
2   libdispatch.dylib             	0x00007fff81f359ee _dispatch_mgr_thread + 54

Thread 2 Crashed:
0   _CppBlockUtils.so             	0x0000000110b68cdb BtcWallet::scanTx(Tx&, unsigned int, unsigned int, unsigned int) + 2095
1   _CppBlockUtils.so             	0x0000000110b69b00 BlockDataManager_FileRefs::scanRegisteredTxForWallet(BtcWallet&, unsigned int, unsigned int) + 402
2   _CppBlockUtils.so             	0x0000000110b69df2 BlockDataManager_FileRefs::scanBlockchainForTx(BtcWallet&, unsigned int, unsigned int) + 478
3   _CppBlockUtils.so             	0x0000000110cbefd6 _wrap_BlockDataManager_FileRefs_scanBlockchainForTx + 1094
4   org.python.python             	0x000000010dce0f72 PyEval_EvalFrameEx + 3557
5   org.python.python             	0x000000010dce0147 PyEval_EvalCodeEx + 1934
6   org.python.python             	0x000000010dce68df 0x10dcc9000 + 121055
7   org.python.python             	0x000000010dce263a PyEval_EvalFrameEx + 9389
8   org.python.python             	0x000000010dce6869 0x10dcc9000 + 120937
9   org.python.python             	0x000000010dce263a PyEval_EvalFrameEx + 9389
10  org.python.python             	0x000000010dce6869 0x10dcc9000 + 120937
11  org.python.python             	0x000000010dce263a PyEval_EvalFrameEx + 9389
12  org.python.python             	0x000000010dce6869 0x10dcc9000 + 120937
13  org.python.python             	0x000000010dce263a PyEval_EvalFrameEx + 9389
14  org.python.python             	0x000000010dce0147 PyEval_EvalCodeEx + 1934
15  org.python.python             	0x000000010dd19d7a 0x10dcc9000 + 331130
16  org.python.python             	0x000000010dcd86c6 PyObject_Call + 97
17  org.python.python             	0x000000010dcf59bf 0x10dcc9000 + 182719
18  org.python.python             	0x000000010dcd86c6 PyObject_Call + 97
19  org.python.python             	0x000000010dce6018 PyEval_CallObjectWithKeywords + 177
20  org.python.python             	0x000000010dd427f6 0x10dcc9000 + 497654
21  libsystem_c.dylib             	0x00007fff8ab29742 _pthread_start + 327
22  libsystem_c.dylib             	0x00007fff8ab16181 thread_start + 13

I just re-downloaded the blockchain.  Sorry, I didn't save the files, although I do have a time machine backup of them from awhile ago.  The fresh download still crashes.

[etotheipi]

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.

[Red Emerald]

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.

[etotheipi]

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

[Red Emerald]

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.

[etotheipi]

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.

Armory 0.84.1-almost-beta

Ubuntu/Debian 64-bit (*.deb)
Windows 64-bit (*.msi)
Windows 32-bit (*.msi)

[cypherdoc]

Bug:  broadcasted a signed offline tx that got sent just fine but Armory had a pop up window that said the tx wouldn't be accepted by the network b/c of lack of a fee. 

[etotheipi]

Bug:  broadcasted a signed offline tx that got sent just fine but Armory had a pop up window that said the tx wouldn't be accepted by the network b/c of lack of a fee. 

You were told it wouldn't broadcast when you created it?  Or when you tried to actually broadcast it (you were able to broadcast it, it showed up on the ledger, but said it failed?)

[cypherdoc]

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

[etotheipi]

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

[cypherdoc]

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

yes, it popped up immediately when i pushed the broadcast button.

[picobit]

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.

[etotheipi]

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.

[cypherdoc]

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.

but i was fully synced.  otherwise the tx wouldn't have gone thru.

[picobit]

but i was fully synced.  otherwise the tx wouldn't have gone thru.

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.

[etotheipi]

but i was fully synced.  otherwise the tx wouldn't have gone thru.

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!

[Morranr]

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.