Red Emerald
|
|
November 10, 2012, 02:17:07 AM |
|
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.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 10, 2012, 03:10:19 AM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 10, 2012, 03:37:45 AM Last edit: November 11, 2012, 06:28:09 PM by etotheipi |
|
New testing release: Armory 0.84.1-almost-betaUbuntu/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
|
|
November 10, 2012, 04:31:01 AM |
|
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. 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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 10, 2012, 04:55:33 AM |
|
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
|
|
November 10, 2012, 07:59:34 AM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 10, 2012, 06:20:11 PM |
|
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
|
|
November 10, 2012, 06:52:02 PM Last edit: November 10, 2012, 07:27:13 PM by 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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 13, 2012, 11:09:26 PM |
|
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-betaUbuntu/Debian 64-bit (*.deb) Windows 64-bit (*.msi)Windows 32-bit (*.msi)
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 15, 2012, 04:17:13 AM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 15, 2012, 04:30:26 AM |
|
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
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 15, 2012, 04:36:50 AM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 15, 2012, 04:38:05 AM |
|
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
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 15, 2012, 04:39:10 AM |
|
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
|
|
November 15, 2012, 08:07:36 AM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 15, 2012, 02:41:07 PM |
|
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
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
November 15, 2012, 02:51:10 PM |
|
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
|
|
November 15, 2012, 08:08:08 PM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
November 16, 2012, 05:08:00 PM |
|
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
Newbie
Offline
Activity: 17
Merit: 0
|
|
November 16, 2012, 06:33:01 PM |
|
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.
|
|
|
|
|