Title: 0.96.1 testing build #4 Post by: goatpig on May 14, 2017, 09:32:57 PM Third testing builds are out.
------------------ Binaries: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4 Fixes/Changes: Code: v0.96.1 -------------- Linux users: If the build fails to run on your setup (unknown instructions), it means your CPU is missing SSE4/AES/PCLMUL instructions. There will be a fail safe gcc4.7 build without any of those instructions for the actual release, but for the testing phase, you'll want to build the code directly on your machine. The build process has been fixed so you should have an easy time with it. -------------- OSX users: Added a build for this version. Title: Re: 0.96.1 testing build #1 Post by: Mr.Vice on May 15, 2017, 10:24:27 AM I'm going to test again encrypting my HDD, but this time I'll use AES 128bit instead of 256bit... maybe this was too heavy in the first place.
Title: Re: 0.96.1 testing build #1 Post by: ask on May 15, 2017, 06:54:36 PM Now works fine. Thank you!
Title: Re: 0.96.1 testing build #1 Post by: gangtraet on May 17, 2017, 07:32:10 AM Does it make sense to attempt a build on my Macbook?
If so, which git branch should I use? Title: Re: 0.96.1 testing build #1 Post by: achow101 on May 17, 2017, 01:40:16 PM Does it make sense to attempt a build on my Macbook? Use the testing branch. Building on macs right now may not work though, but you can try.If so, which git branch should I use? Title: Re: 0.96.1 testing build #1 Post by: gangtraet on May 17, 2017, 08:36:38 PM Use the testing branch. Building on macs right now may not work though, but you can try. Same problem as with the master branch: It builds just fine, but cannot run. Starting it on the command line gives this error: Code: 22:28 workspace$ Armory.app/Contents/MacOS/Armory Manually copying ArmoryQt.py into that location gives a new error: Code: 22:29 workspace$ Armory.app/Contents/MacOS/Armory Title: Re: 0.96.1 testing build #1 Post by: helgabutters on May 18, 2017, 09:04:45 PM A minor bug in sending/coin control I noticed.
If you go into "Coin Control" and deselect everything (or only select things that have a 0.00 balance), you can still successfully create a transaction if your amount sent is below your wallet balance. You are not prompted with the "Coin Selection Failure: Coin selection failed with error: spend value > usable balance" as expected. I'm not sure the logic but it seems to just pick from any coins in the wallet, although to be fair there is only P2PKH outputs in what I'm testing. Title: Re: 0.96.1 testing build #1 - ArmoryDB loses connection to bitcoind... Post by: Mr.Vice on May 19, 2017, 09:14:58 AM ArmoryDB always loses connection after StopBlockingLoop Exception in ProcessDataThread and can't re-establish it.
Afterward I exit ArmoryQt normally and after restarting it the GUI can not update anymore (ArmoryDB won't even start again in Background)! My Laptop is completely unencrypted now, so that can not be the issue. It seems this is happening always when ArmoryDB is loading the hashes of new blocks, while Bitcoin Core hasn't got the complete blocks yet. I always have to do a rebuid and rescan and to be serious I just can not do that anymore (goatpig knows what I mean). Code: -ERROR - 11:05:40.515: (..\BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread Title: Re: 0.96.1 testing build #1 - ArmoryDB loses connection to bitcoind... Post by: Mr.Vice on May 19, 2017, 09:37:14 AM Code: -INFO - 11:28:30.016: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:248) Listening on port 9001 I'm using Bitcoin Core 0.14.1 together with 0.96.0.1-testing but anyway this issue with the StopBlockingLoop exception I also ha running 0.96 (also with unencrpyted HDD). So normally this shows up when terminating ArmoryQt, but while it's actually running is also strange to me. Title: Re: 0.96.1 testing build #1 - ArmoryDB loses connection to bitcoind... Post by: goatpig on May 19, 2017, 11:42:05 AM ArmoryDB always loses connection after StopBlockingLoop Exception in ProcessDataThread and can't re-establish it. Code: -ERROR - 11:05:40.515: (..\BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread This means your node dropped the DB p2p connection. Usually that's because the node was shutdown. Unless you enforce a node limit, there is no reason for your node to just kick the DB out of its peer node. If you are triggering this, you need to figure out how. Quote Afterward I exit ArmoryQt normally and after restarting it the GUI can not update anymore (ArmoryDB won't even start again in Background) That suggests the DB is still running and didn't shutdown with the client. When this happens, try to run the DB on its own, see how it behaves. Quote I always have to do a rebuid and rescan and to be serious I just can not do that anymore (goatpig knows what I mean). What you are describing does not require a rebuild of the db. Title: Re: 0.96.1 testing build #1 - ArmoryDB loses connection to bitcoind... Post by: Mr.Vice on May 19, 2017, 03:03:19 PM ArmoryDB always loses connection after StopBlockingLoop Exception in ProcessDataThread and can't re-establish it. Code: -ERROR - 11:05:40.515: (..\BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread This means your node dropped the DB p2p connection. Usually that's because the node was shutdown. Unless you enforce a node limit, there is no reason for your node to just kick the DB out of its peer node. If you are triggering this, you need to figure out how. Quote Afterward I exit ArmoryQt normally and after restarting it the GUI can not update anymore (ArmoryDB won't even start again in Background) That suggests the DB is still running and didn't shutdown with the client. When this happens, try to run the DB on its own, see how it behaves. Quote I always have to do a rebuid and rescan and to be serious I just can not do that anymore (goatpig knows what I mean). What you are describing does not require a rebuild of the db. Yes, it pretty much seems that there is some kind of unique condition. So, the only thing that's so harsh on executing programs could only be my McAfee Anti-Virus software. Although it has worked fine up to 0.95.1 together with Core 0.13.1. Hmmm, anyway I have deinstalled that and I'm using now windows defender only (also added exceptions for the real-time scanner at C:\..\AppData\Armory & AppData\Bitcoin Core directories). I'm currently at rebuid&rescan because I have read it too late that it would not be nesassary. If this is still not working I'll maybe format my HDD and after fresh installing Win10 Armory will be the only program that's executed at first. Title: Re: 0.96.1 testing build #1 Post by: alomar on May 19, 2017, 03:19:58 PM is the hashed *.deb correct? i can't get them to match. what's the "gcc" build?:
Hash: SHA256 64f4b4295210bbe65ce9e3b485f78f06e723fa7e7209d5f244d1265a175ed6f1 armory_0.96-gcc4.7_amd64.deb 987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2 armory_0.96-gcc5.4_amd64.deb fce84bd0964a43a677b1be689e321c562c10a202a35fd052975f3c3536055dd7 armory_0.96_win64.exe dfa1dec7590e2cfc3dfe718a9fc0104108795fe9a55cdb43edf4de56e396caa7 armory_0.96_win64.zip debian@debian:~/Downloads$ sha256sum armory_0.96.0.1-testing_amd64.deb 25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783 armory_0.96.0.1-testing_amd64.deb Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 19, 2017, 05:03:27 PM is the hashed *.deb correct? i can't get them to match. what's the "gcc" build?: Hash: SHA256 64f4b4295210bbe65ce9e3b485f78f06e723fa7e7209d5f244d1265a175ed6f1 armory_0.96-gcc4.7_amd64.deb 987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2 armory_0.96-gcc5.4_amd64.deb fce84bd0964a43a677b1be689e321c562c10a202a35fd052975f3c3536055dd7 armory_0.96_win64.exe dfa1dec7590e2cfc3dfe718a9fc0104108795fe9a55cdb43edf4de56e396caa7 armory_0.96_win64.zip debian@debian:~/Downloads$ sha256sum armory_0.96.0.1-testing_amd64.deb 25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783 armory_0.96.0.1-testing_amd64.deb Version mismatch Title: Re: 0.96.1 testing build #1 Post by: alomar on May 19, 2017, 06:30:44 PM is the hashed *.deb correct? i can't get them to match. what's the "gcc" build?: Hash: SHA256 64f4b4295210bbe65ce9e3b485f78f06e723fa7e7209d5f244d1265a175ed6f1 armory_0.96-gcc4.7_amd64.deb 987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2 armory_0.96-gcc5.4_amd64.deb fce84bd0964a43a677b1be689e321c562c10a202a35fd052975f3c3536055dd7 armory_0.96_win64.exe dfa1dec7590e2cfc3dfe718a9fc0104108795fe9a55cdb43edf4de56e396caa7 armory_0.96_win64.zip debian@debian:~/Downloads$ sha256sum armory_0.96.0.1-testing_amd64.deb 25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783 armory_0.96.0.1-testing_amd64.deb Version mismatch not sure i understand. is there an error in the hashes of the sha256sum.txt.asc file that are indeed mismatched with the hash of the *.deb file? if so, how are we supposed to verify that we have an original build? Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 19, 2017, 06:58:51 PM 987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2 armory_0.96-gcc5.4_amd64.deb
25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783 armory_0.96.0.1-testing_amd64.deb Title: Re: 0.96.1 testing build #1 Post by: alomar on May 19, 2017, 07:32:37 PM 987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2 armory_0.96-gcc5.4_amd64.deb 25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783 armory_0.96.0.1-testing_amd64.deb thank you. Title: Re: 0.96.1 testing build #1 - ArmoryDB loses connection to bitcoind... Post by: Mr.Vice on May 19, 2017, 09:53:22 PM Quote Yes, it pretty much seems that there is some kind of unique condition. So, the only thing that's so harsh on executing programs could only be my McAfee Anti-Virus software. Although it has worked fine up to 0.95.1 together with Core 0.13.1. Hmmm, anyway I have deinstalled that and I'm using now windows defender only (also added exceptions for the real-time scanner at C:\..\AppData\Armory & AppData\Bitcoin Core directories). I'm currently at rebuid&rescan because I have read it too late that it would not be nesassary. If this is still not working I'll maybe format my HDD and after fresh installing Win10 Armory will be the only program that's executed at first. @goatpig: I finally knew what was causing this issues! I've found 3 virues/trojans that tried to prevent core from connecting to other clients, armorydb from connecting with core and where hiding in my blockchain files! They where sleeping in my old recovery folder (that I imported from my old laptop) and spreaded in my account. My hole laptop was so incedibly slow from day to day even slower... I have wiped out my hole app data of armory and bitcoin and afterwards boom.. everything was running smooth again. I'm now downloading the hole blockchain, but everything goes extremly fast now. I had excluded certain folders from scanning because I fought they might corrupt the blockchain... anyway thanks for helping me goatpig! How can I change to usse tor settings, the button in the GUI is broken... what do I have to write in the config file and how is it named?... pls.. #JOHN MCAFEE ROCKS! =D Title: Re: 0.96.1 testing build #1 - ArmoryDB loses connection to bitcoind... Post by: goatpig on May 20, 2017, 01:12:46 PM Quote Yes, it pretty much seems that there is some kind of unique condition. So, the only thing that's so harsh on executing programs could only be my McAfee Anti-Virus software. Although it has worked fine up to 0.95.1 together with Core 0.13.1. Hmmm, anyway I have deinstalled that and I'm using now windows defender only (also added exceptions for the real-time scanner at C:\..\AppData\Armory & AppData\Bitcoin Core directories). I'm currently at rebuid&rescan because I have read it too late that it would not be nesassary. If this is still not working I'll maybe format my HDD and after fresh installing Win10 Armory will be the only program that's executed at first. @goatpig: I finally knew what was causing this issues! I've found 3 virues/trojans that tried to prevent core from connecting to other clients, armorydb from connecting with core and where hiding in my blockchain files! They where sleeping in my old recovery folder (that I imported from my old laptop) and spreaded in my account. My hole laptop was so incedibly slow from day to day even slower... I have wiped out my hole app data of armory and bitcoin and afterwards boom.. everything was running smooth again. I'm now downloading the hole blockchain, but everything goes extremly fast now. I had excluded certain folders from scanning because I fought they might corrupt the blockchain... anyway thanks for helping me goatpig! How can I change to usse tor settings, the button in the GUI is broken... what do I have to write in the config file and how is it named?... pls.. #JOHN MCAFEE ROCKS! =D There are a few false positives in the blockchain, where people pushed virus signatures in transactions. That's enough to get your antivirus to freak out. These cases were reported as false positives but who knows what the AV companies did with those reports. Consider that a resident AV's heuristics alone can nuke on disk content post flush basically at its own whim. Chances are the AV created issues where they were none to begin with. Objectively, an AV is no different from a virus: it resides on your system, constantly eats resources and damages the user experience. My advice to you, whether you let the AV run or not, is to make periodical copies of a valid blockchain data folder on external storage to restore faster. As for the config files, they are named armoryqt.conf and armorydb.conf and go in your Armory datadir (where your wallets reside). Any command line you can give to either process you can put in the relevant config file. If you are running with default paths, there isn't anything you need to put in there. If you want to run the lighter DB, use --dbtype=DB_BARE. There is no more "use tor setting" per se. There is no more phone home code in Armory, the only piece of software in the stack that uses the WAN is your node. Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 20, 2017, 01:15:29 PM Hi I noticed, that my Armory seems to not pick up new blocks. It seems to be stuck on Block 465695. It says Online but does not go any further. Starting core alone is fine and goes all the way to the top, so I tried running core manuely with no success. Then it says offline. Code: -INFO - 13:17:55: (DatabaseBuilder.cpp:477) Found next block after skipping 510159bytes It's skipping a block for some reason. Try a rebuild & rescan, if that doesn't fix it, you'll have to delete all your blkXXXXX.dat files starting #860 Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 23, 2017, 08:00:55 PM Need to see the log for the second build&scan
Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 25, 2017, 08:25:15 PM This DB never got really far. Are you using an anti virus too? Your blockchain data keeps getting corrupted after the fact.
Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 25, 2017, 10:20:10 PM So I checked and I actually had clamav installed. I am pretty sure thought, that it didn't do anything, since I didn't let it delete anything. I also have ufw installed, which also shouldn't do anything. Can I make Bitcoin Core check the blockchain maybe? I didn't find any option for that anywhere. Not sure what the name of the arg is, something like "-checkchain". Make sure to delete your armory databases folder after that. Title: Re: 0.96.1 testing build #1 Post by: Portnoy on May 26, 2017, 01:14:07 AM So I checked and I actually had clamav installed. I am pretty sure thought, that it didn't do anything, since I didn't let it delete anything. I also have ufw installed, which also shouldn't do anything. Can I make Bitcoin Core check the blockchain maybe? I didn't find any option for that anywhere. Not sure what the name of the arg is, something like "-checkchain". Make sure to delete your armory databases folder after that. https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments Title: Re: 0.96.1 testing build #1 Post by: Mr.Vice on May 26, 2017, 10:05:01 AM @goatpig: I just wanted to thank you for everything man, finally everything works with Armory 0.96.1-testing. There where multiple issues that have caused my unique problem.
1): McAfee AV was configured to (not only) real-time scanning, but also with the option of direct blocking "threats" before written on HDD. 2): Encrypted HDD with AES-CBC 256bit. 3): Custom bitcoin.conf with server=1 and the old rpcuser & rpcpasswords set that are deprecated now (cookie-auth). Code: ## CONNECTION So many thanks for your help goatpig! I was able to run McAfee together with Armory now by deactivating some settings, but it was one of the reasons why it didn't work in the first place. Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 26, 2017, 10:51:42 AM @goatpig: I just wanted to thank you for everything man, finally everything works with Armory 0.96.1-testing. There where multiple issues that have caused my unique problem. 1): McAfee AV was configured to (not only) real-time scanning, but also with the option of direct blocking "threats" before written on HDD. 2): Encrypted HDD with AES-CBC 256bit. 3): Custom bitcoin.conf with server=1 and the old rpcuser & rpcpasswords set that are deprecated now (cookie-auth). cookie auth replaces rpclogin/password You need server=1 to enable the RPC though. Title: Re: 0.96.1 testing build #1 Post by: creamers on May 29, 2017, 08:58:46 PM Hi !
I've been using a cold armory wallet on my ubuntu pi version 94.x and a online version on server 2008R2 94.x. Core is version 13.x (if I'm not mistaken) Q: should I download en just install everything on the 'online' server without deinstalling stuff first ? What do you advice ? Q: is my cold wallet still usable with the new versions ? When isnt it usable anymore? Q: I assume my paper wallet is still usable on the new armory version? Thanks in advance ... Hopefully it's gonna be a nice migration ;D Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 30, 2017, 06:55:05 AM Q: should I download en just install everything on the 'online' server without deinstalling stuff first ? What do you advice ? If you are updating from 0.94, you will need to delete your Armory database as it is not compatible with 0.95+. The installer just replace the binaries. Uninstalling does not wipe the user data (db/wallets/settings), so you will have to wipe the db data manually. Quote Q: is my cold wallet still usable with the new versions ? When isnt it usable anymore? No difference with 0.95. 0.96 default settings are backwards compatible with up to 0.92. If you use the new scripts types (deviate from the defaults), you will need a 0.96+ signer. Quote Q: I assume my paper wallet is still usable on the new armory version? This stuff will always be supported. Title: Re: 0.96.1 testing build #1 Post by: creamers on May 30, 2017, 08:23:15 PM I first updated bitcoin core to the latest version. This went without problem.
"C:\Program Files\Bitcoin\bitcoin-qt.exe" -datadir="D:\Bitcoin Core Database" After this I removed the old armory database and installed armory. (not deinstalled the armory client) I started armory: "C:\Program Files (x86)\Armory\ArmoryQt.exe" --datadir="D:\Armory Database" --satoshi-datadir="D:\Bitcoin Core Database" After a while I got this error: http://i65.tinypic.com/10r7g1t.png Code: (ERROR) ArmoryUtils.pyc:3744 - Unsupported language specified. Defaulting to English (en) armorylog.txt https://pastebin.com/Q7CaghHj (https://pastebin.com/Q7CaghHj) dblog.txt https://pastebin.com/XVCK9Qyv (https://pastebin.com/XVCK9Qyv) Then I saw this in eventlog on server 2008R2: Quote Windows cannot access the file D:\Bitcoin Core Database\blocks\blk00646.dat for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program ArmoryDB.exe because of this error. Strange reason. There is no virusscanner installed and the file is accessible. What should be the next step.? Should I try again or are there things you need to know before I do, so you can solve this for future updates? Title: Re: 0.96.1 testing build #1 Post by: goatpig on May 30, 2017, 08:55:17 PM Is D: a USB drive?
Title: Re: 0.96.1 testing build #1 Post by: creamers on May 31, 2017, 03:24:10 PM Is D: a USB drive? No, a second (raid 1) volume/disk. (same disk where bitcoin core stores it's database) I'll try to start bitcoin core again and see if it syncs up. Then I'll try armory again. *EDIT: so far so good the second time around: http://imgur.com/a/0b9fS Title: Re: 0.96.1 testing build #1 Post by: creamers on May 31, 2017, 08:14:47 PM Unfortunately it crashed again at a higher % but the application eventlog says it has to do with the same file (blk00646.dat).
http://imgur.com/a/XitHD (http://imgur.com/a/XitHD) After closing the crash notification window if found some more info in the logfiles. Maybe this clears things up? The strange thing about this is that I've been using the old version and the old bitcoin core already for a long time on this server, there should be something that causes this. If we find it, it will be beneficial for others and new users. Quote -INFO - 19:28:30.643: (..\DatabaseBuilder.cpp:268) parsed block file #647 -INFO - 19:29:02.015: (..\DatabaseBuilder.cpp:268) parsed block file #649 -INFO - 19:33:55.406: (..\DatabaseBuilder.cpp:268) parsed block file #651 -INFO - 19:34:11.584: (..\DatabaseBuilder.cpp:268) parsed block file #653 -ERROR - 22:04:06.118: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10022 -ERROR - 22:04:06.211: (..\BitcoinP2P.cpp:1027) caught SocketError exception in processDataStackThread: poll() error in writeToSocket: 10022 -INFO - 22:04:06.320: (..\BitcoinP2P.cpp:969) Disconnected from Bitcoin node Quote 2017-05-31 19:34:11 (INFO) -- ArmoryQt.py:4606 - Dashboard switched to "Scanning" mode 2017-05-31 22:04:29 (INFO) -- ArmoryQt.py:5389 - BDM state is scanning -- force shutdown BDM 2017-05-31 22:04:29 (INFO) -- SDM.pyc:456 - Called stopBitcoind 2017-05-31 22:04:31 (ERROR) -- ArmoryQt.py:5402 - Strange error during shutdown Traceback (most recent call last): File "ArmoryQt.py", line 5393, in closeForReal File "SDM.pyc", line 482, in stopBitcoind File "armoryengine\ArmoryUtils.pyc", line 828, in LOGERROR TypeError: cannot concatenate 'str' and 'exceptions.RuntimeError' objects 2017-05-31 22:04:31 (INFO) -- ArmoryQt.py:5404 - Attempting to close the main window! Restarted the 2008R2 server and running armory for the third time to see what happens. Title: Re: 0.96.1 testing build #1 Post by: Betatester on June 01, 2017, 12:07:32 PM -------------- Linux users: If the build fails to run on your setup (unknown instructions), it means your CPU is missing SSE4/AES/PCLMUL instructions. There will be a fail safe gcc4.7 build without any of those instructions for the actual release, but for the testing phase, you'll want to build the code directly on your machine. The build process has been fixed so you should have an easy time with it. -------------- So what setup (Distro, CPU, RAM) did you use for those builds? I will buy such a machine to get my coins sent. Title: Re: 0.96.1 testing build #1 Post by: creamers on June 01, 2017, 01:02:05 PM Quote Restarted the 2008R2 server and running armory for the third time to see what happens. Same problem again at the same percentage. any suggestions ? Title: Re: 0.96.1 testing build #1 Post by: Mr.Vice on June 02, 2017, 09:37:28 AM @goatpig:
server=1 and cookie auth works fine... actually everything essential works well! :-D There are only some minor bugs left regarding the property window (address explorer like I call it). E.g. in the offline version the right click options don't work and the pop-up window when clicking on specific addresses does not show up. And when you are in the sending dialoge and open the address book you can not select addresses. You have to right click and copy/paste the address in order to select it. Title: Re: 0.96.1 testing build #1 Post by: Mr.Vice on June 02, 2017, 04:57:22 PM Unfortunately it crashed again at a higher % but the application eventlog says it has to do with the same file (blk00646.dat). http://imgur.com/a/XitHD (http://imgur.com/a/XitHD) After closing the crash notification window if found some more info in the logfiles. Maybe this clears things up? The strange thing about this is that I've been using the old version and the old bitcoin core already for a long time on this server, there should be something that causes this. If we find it, it will be beneficial for others and new users. Quote -INFO - 19:28:30.643: (..\DatabaseBuilder.cpp:268) parsed block file #647 -INFO - 19:29:02.015: (..\DatabaseBuilder.cpp:268) parsed block file #649 -INFO - 19:33:55.406: (..\DatabaseBuilder.cpp:268) parsed block file #651 -INFO - 19:34:11.584: (..\DatabaseBuilder.cpp:268) parsed block file #653 -ERROR - 22:04:06.118: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10022 -ERROR - 22:04:06.211: (..\BitcoinP2P.cpp:1027) caught SocketError exception in processDataStackThread: poll() error in writeToSocket: 10022 -INFO - 22:04:06.320: (..\BitcoinP2P.cpp:969) Disconnected from Bitcoin node @creamers: I think I know what's causing your problem. I've gotten a similar issue when I was upgrading to Core (0.14+) and Armory (0.96+). The Bitcoin Core versions since 0.14 can cause a right management bug on Windows machines, which does not affect BitcoinQt, but every software that runs on top of it. Could you please check the properties of your Bitcoin folder by right clicking on the folder, selecting properties, tab security and go to extended or additional (I'm not sure how that button is called in English, it's the last one at the bottom). Now you'll see another pop-up window where it says "owner:". When it says "SYSTEM" you have to change that into your local user's account, otherwise you'll ran into the same issue over and over. Afterwards start BitcoinQt only and let it completely sync the blockchain. Then exit BitcoinQt, go to your Bitcoin folder and modify your bitcoin.conf file. Remove the lines with rpcuser and rpcpassword, add the following line "server=1" and save it. Now let Armory do a rebuild & rescan and everything should work fine. Title: Re: 0.96.1 testing build #1 Post by: creamers on June 03, 2017, 10:47:02 AM Thx mr Vice, but unfortunately it didnt work out for me. I'm logged in as administrator and it was already owner of the folder and has full permissions.
I did change it to server=1. Still crashing at some %. I also copied everything from the bitcoincore database folder to a new folder to make sure windows hasnt a problem with the file. Bitcoin core also hasnt a problem with it's own database. armorylog since the beginning with all the errors in it: https://pastebin.com/QUSgMCd5 dblog since: https://pastebin.com/DaDhxH63 Bitcoincore is now catching up and I'm running armory with an unchecked 'let armory run bitcoind in background' to see what happens. Hope someone can make sence out of the logfiles to solve this for me and others who want to update from older versions. *EDIT:
Title: Re: 0.96.1 testing build #1 Post by: goatpig on June 03, 2017, 04:42:36 PM Ima push another build tomorrow, try with that then.
Title: Re: 0.96.1 testing build #1 Post by: creamers on June 04, 2017, 07:15:09 AM Thank you.
It ran all night, but after importing a paper backup, armorydb.exe was very busy and finally it crashed with the following in the logfiles: armorylog Quote 2017-06-04 08:34:08 (INFO) -- qtdialogs.pyc:10895 - Wallet Restore Complete! armorycpplog Quote Log file opened at 18:42:54.000: D:\Armory Database\armorycpplog.txt -ERROR - 17:27:46.070: (..\SocketObject.cpp:440) POLLERR error in readAndWrite Log file opened at 17:38:34.000: D:\Armory Database\armorycpplog.txt -ERROR - 22:04:07.928: (..\SocketObject.cpp:440) POLLERR error in readAndWrite Log file opened at 22:09:55.000: D:\Armory Database\armorycpplog.txt -ERROR - 14:58:31.580: (..\SocketObject.cpp:440) POLLERR error in readAndWrite Log file opened at 11:18:23.000: D:\Armory Database\armorycpplog.txt Log file opened at 12:33:37.000: D:\Armory Database\armorycpplog.txt Log file opened at 16:26:35.000: D:\Armory Database\armorycpplog.txt -ERROR - 16:26:42.942: (c:\users\goat\code\armory3\cppforswig\DataObject.h:286) exhausted entries in Arguments object -ERROR - 16:26:42.942: (..\SwigClient.cpp:61) exhausted entries in Arguments object Log file opened at 16:30:31.000: D:\Armory Database\armorycpplog.txt Log file opened at 19:22:08.000: D:\Armory Database\armorycpplog.txt -ERROR - 21:47:03.277: (..\SocketObject.cpp:440) POLLERR error in readAndWrite Log file opened at 21:47:58.000: D:\Armory Database\armorycpplog.txt Log file opened at 22:02:54.000: D:\Armory Database\armorycpplog.txt Log file opened at 23:46:04.000: D:\Armory Database\armorycpplog.txt dblog Quote -INFO - 09:00:01.737: (..\BlockchainScanner.cpp:650) scanned from height #430571 to #431600 -INFO - 09:00:15.183: (..\BlockchainScanner.cpp:650) scanned from height #431601 to #432267 -INFO - 09:00:30.488: (..\BlockchainScanner.cpp:650) scanned from height #432268 to #432970 -INFO - 09:00:43.452: (..\BlockchainScanner.cpp:650) scanned from height #432971 to #433637 -INFO - 09:00:44.981: (..\BlockchainScanner.cpp:650) scanned from height #433638 to #433787 -INFO - 09:00:44.293: (..\BlockchainScanner.cpp:225) scanned transaction history in 1596.52s -INFO - 09:00:45.698: (..\BlockchainScanner.cpp:1560) resolving txhashes -INFO - 09:02:22.824: (..\BlockchainScanner.cpp:1616) 11 blocks hit by tx filters -ERROR - 09:02:24.696: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters: -ERROR - 09:02:24.712: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash -ERROR - 09:02:24.712: (..\BlockchainScanner.cpp:1407) Skipping this block -ERROR - 09:02:24.712: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters: -ERROR - 09:02:24.728: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash -ERROR - 09:02:24.728: (..\BlockchainScanner.cpp:1407) Skipping this block -ERROR - 09:02:26.005: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters: -ERROR - 09:02:26.005: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash -ERROR - 09:02:26.021: (..\BlockchainScanner.cpp:1407) Skipping this block -ERROR - 09:02:26.021: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters: -ERROR - 09:02:26.036: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash -ERROR - 09:02:26.036: (..\BlockchainScanner.cpp:1407) Skipping this block -ERROR - 09:02:26.348: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters: -ERROR - 09:02:26.364: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash -ERROR - 09:02:26.364: (..\BlockchainScanner.cpp:1407) Skipping this block -ERROR - 09:02:26.364: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters: -ERROR - 09:02:26.395: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash -ERROR - 09:02:26.395: (..\BlockchainScanner.cpp:1407) Skipping this block Here it crashed! 469666 blocks are shown in BitcoinCore and it's uptodate, but Armory only shows 433xxx blocks and is online ?! That's probably also the reason that I don't have a correct end balance and missing transactions. I'll try 0.96.2 , let me know what you want me to do/test. Title: Re: 0.96.1 testing build #1 Post by: Mr.Vice on June 04, 2017, 08:11:34 PM Quote Thx mr Vice, but unfortunately it didnt work out for me. I'm logged in as administrator and it was already owner of the folder and has full permissions. I did change it to server=1. Still crashing at some %. @creamers: I'm sorry to hear that :-/ Actually I've been undergoing quite similar issues like you are with Core (0.14+) and Armory (0.96+). These issues where mostly caused by AntiVirus software (McAfee), to be specific it was due to the real-time scanner. I'm not sure if I remember it right that Windows Server R2 2008 has a buildt in Windows Defender? Because from what I know WinDef hasn't really changed over the years (Win10 has practically no difference with the ones in Vista, 7 etc.). What I've done was first uninstalling all McAfee AV files and so on and tried running Core and Armory only with WinDef. But that hasn't worked verry well either. To prevent it from interfering you have two options: deactivate real-time scanner or set up exceptions for specific directories. For me that worked, so I really hope you can solve it the same way. 1) Exceptions for the following paths: C:\Users\..\AppData\Roaming\Bitcoin (or your specific Core folder) C:\Users\..\AppData\Roaming\Armory (like above) 2) Exceptions for the following processes: C:\ProgramFiles\Armory\ArmoryQt.exe (please look up your installation path, it may differ from mine) C:\ProgramFiles\Bitcoin\bitcoin-qt.exe (like above) C:\ProgramFiles\Bitcoin\bitcoind.exe (like above) But I would first recommend to just deactivate real-time scanner of WinDef to test if this is the cause (I do not want to hurt your security with my recommendations, so if you're not sure about that you should skip this and try the exceptions first). After that delete your database folder of the Armory directory to force a rebuild & rescan. Another thing I've noticed is that WinDef might interfer in the shut-down process of Armory, where some processes in background are still running even if you closed it properly. So to ensure that isn't the case I would also prefer to restart your server before you try to run Armory again (if restarting is possible for you - or if it has to be online 24/7). Title: Re: 0.96.1 testing build #1 Post by: creamers on June 04, 2017, 09:01:52 PM @creamers: I'm sorry to hear that :-/ Actually I've been undergoing quite similar issues like you are with Core (0.14+) and Armory (0.96+). These issues where mostly caused by AntiVirus software (McAfee), to be specific it was due to the real-time scanner. I'm not sure if I remember it right that Windows Server R2 2008 has a buildt in Windows Defender? Because from what I know WinDef hasn't really changed over the years (Win10 has practically no difference with the ones in Vista, 7 etc.). What I've done was first uninstalling all McAfee AV files and so on and tried running Core and Armory only with WinDef. But that hasn't worked verry well either. To prevent it from interfering you have two options: deactivate real-time scanner or set up exceptions for specific directories. For me that worked, so I really hope you can solve it the same way. Good tip for others , but I don't have a virusscanner on my nas ;) I see in the armory thread that others have crashes to, I'll wait for the .2 test version to help out testing this. :) Title: Re: 0.96.1 testing build #1 Post by: goatpig on June 04, 2017, 09:17:40 PM Wait, you're using a NAS? Armory doesn't work all that well with that stuff because it mmaps every file on disk.
Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 04, 2017, 11:08:37 PM Added new builds.
Title: Re: 0.96.1 testing build #2 Post by: treeset on June 05, 2017, 07:52:45 AM Great!
Tried build armory_0.96.0.2-testing_win64.exe. The memory problem as described in https://bitcointalk.org/index.php?topic=1947650.0 (https://bitcointalk.org/index.php?topic=1947650.0) is solved! Used memory stays around 1,5 - 2 GB, and never gets filled up now. No pagefile swapping anymore. Armory finishes in 9 minutes for first build of the databases and getting online! Thank you for fixing the memory issue! Title: Re: 0.96.1 testing build #2 Post by: Mr.Vice on June 05, 2017, 11:09:42 AM Yeah!! Armory 0.96.01-testing build #2 rocks :-D
Everything's running pretty well so far. The address book functionality is still limited though (choosing addresses by pressing selection button still does'nt work), but that's just a minor bug. I've experimentet a little with AV + Armory and it works when in your software ArmoryDB.exe has every incoming and outgoing port opened. When you're running it with "certain ports only (McAfee actually recommends this)" then it just opens a few static ports. So choosing "open for all devices" will let ArmoryDB receive every "lost" blocks between Core, without needing for rebuild&rescan. That might be the reason why every version before 0.96 has worked, since ArmoryDB I think has used a static port, which has changed to dynamic port selection. Title: Re: 0.96.1 testing build #2 Post by: creamers on June 05, 2017, 11:32:49 AM I've always ran armory and bitcoin core on my HP proliant microserver without problem.
I've tested the second build 0.96.2 and it now finish without an error. ;D But, somehow armory is not seeing the whole bitcoin core chain, but will continue in another thread as this version seems to work fine now and I'm having (probably) another problem. Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 05, 2017, 11:42:13 AM Yeah!! Armory 0.96.01-testing build #2 rocks :-D Everything's running pretty well so far. The address book functionality is still limited though (choosing addresses by pressing selection button still does'nt work), but that's just a minor bug. I knew I forgot about something... Can you elaborate on the issue, will look at it this week. Quote I've experimentet a little with AV + Armory and it works when in your software ArmoryDB.exe has every incoming and outgoing port opened. When you're running it with "certain ports only (McAfee actually recommends this)" then it just opens a few static ports. So choosing "open for all devices" will let ArmoryDB receive every "lost" blocks between Core, without needing for rebuild&rescan. That might be the reason why every version before 0.96 has worked, since ArmoryDB I think has used a static port, which has changed to dynamic port selection. People were complaining about the static port conflicting, so the setup has changed. When your client spawns the DB, it will use a dynamic port. More specifically when the db is spawned with --cookie, it will randomize its port and report it in its cookie file. You can force the port to a custom value however, using --fcgi-port. Try setting that in your armorydb.conf and letting the client spawn the DB for you. Quote But, somehow armory is not seeing the whole bitcoin core chain Did you perform a full rebuild and rescan with .0.2? Title: Re: 0.96.1 testing build #2 Post by: Wiegerwijnia on June 05, 2017, 06:10:56 PM This version is maybe missing some files in the installer under ubuntu ?
I am getting errors with setting up menu items that armory_icon_64x64.png is missing. I cannot start the application also, i get an error launching the application. Title: Re: 0.96.1 testing build #2 Post by: Mr.Vice on June 06, 2017, 10:14:04 AM Quote Quote Quote from: Mr.Vice on June 05, 2017, 11:09:42 AM Yeah!! Armory 0.96.01-testing build #2 rocks :-D Everything's running pretty well so far. The address book functionality is still limited though (choosing addresses by pressing selection button still does'nt work), but that's just a minor bug. I knew I forgot about something... Can you elaborate on the issue, will look at it this week. I will check it out in later builds as well. Great, thx! ;-) Quote Quote from: Mr.Vice on June 02, 2017, 09:59:14 AM I've also found another bug in Armory Offline 0.96.0.1-testing. When I want to display already generated addresses again I can not use the right click options e.g. copy, show on blockchain.info, etc. nor I can spawn a pop-up window in the wallet's address explorer. Is this a known issue? Quote Which dialog is this happening in? This is happening in the Wallets Properties dialog window in the offline version of Armory (also testing build #2). E.g. when selecting a specific address in the wallet you can not use the right-click options, neither can you double-click and display the address ledger of a specific address (for QR code or public/private keys of addresses). Kind regards :-) Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 06, 2017, 11:44:41 AM This is happening in the Wallets Properties dialog window in the offline version of Armory (also testing build #2). E.g. when selecting a specific address in the wallet you can not use the right-click options, neither can you double-click and display the address ledger of a specific address (for QR code or public/private keys of addresses). Kind regards :-) Double click works for me. Can you try to narrow it down? Which area of the line are you clicking? As for right click menu, there isn't one for this dialog. Title: Re: 0.96.1 testing build #2 Post by: bureaucrat on June 06, 2017, 02:05:30 PM Hello, Im trying to install 0.96.1 testing build #2 to OS X (10.12.5) but it doesn't even starts
Bitcoin core installed, but not synced yet. Please help me to understand how to make it work with Mac. Thanks! Code: Exception Type: EXC_CRASH (SIGABRT) Title: Re: 0.96.1 testing build #2 Post by: gangtraet on June 06, 2017, 06:39:35 PM I tried again to build for OS X. The same problem as previously appeared: ArmoryQt.py is not copied into the .app
If I copy it in manually, then it fails when it tries to Code: import CppBlockUtils as Cpp To me, it looks like all prerequisites are compiled and installed in the .app, but Armory itself is not. Title: Re: 0.96.1 testing build #2 Post by: Mr.Vice on June 07, 2017, 07:43:14 AM This is happening in the Wallets Properties dialog window in the offline version of Armory (also testing build #2). E.g. when selecting a specific address in the wallet you can not use the right-click options, neither can you double-click and display the address ledger of a specific address (for QR code or public/private keys of addresses). Kind regards :-) Double click works for me. Can you try to narrow it down? Which area of the line are you clicking? As for right click menu, there isn't one for this dialog. I've done the following steps: 1) Execute "Bitcoin Armory (Offline)". 2) Then I choose a wallet from the list of "available wallets" in the Main Window and double-click on the row with the selected wallet. 3) Now the "Wallet Properties" Window opens. 4) From there I expand the drop-down list of the "unused addresses" expander. 5) Another 3 expanders will be displayed for the address types (P2PKH, P2SH-P2PK, P2SH-P2WPKH). I expand the "P2PKH" expander list. 6) All addresses of this type are displayed. Now I choose any of them and double-click on the address column of the table. This is the layer where nothing pops up, so I can not copy and paste that address. In Armory Online there is a pop-up window from where I can copy that address or display public/private keys of that address. armorylog.txt Code: 2017-06-07 09:29:58 (WARNING) -- ArmoryQt.py:1828 - Not online, will not start bitcoind Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 07, 2017, 12:23:49 PM Ah I see. That can only happen in offline mode. Will push the fix in a few.
Title: Re: 0.96.1 testing build #2 Post by: droark on June 08, 2017, 03:09:37 AM I tried again to build for OS X. The same problem as previously appeared: ArmoryQt.py is not copied into the .app If I copy it in manually, then it fails when it tries to Code: import CppBlockUtils as Cpp To me, it looks like all prerequisites are compiled and installed in the .app, but Armory itself is not. That means there's some sort of compile error when compiling the Armory code. Are you following the build notes? (https://github.com/goatpig/BitcoinArmory/blob/dev/osxbuild/OSX_build_notes.md) If so, what's your setup? Title: Re: 0.96.1 testing build #2 Post by: Mr.Vice on June 08, 2017, 09:14:17 AM Ah I see. That can only happen in offline mode. Will push the fix in a few. Great, thx! :-) There is a type of import addresses that is not supported by Armory, currently. Although Core does support it. I can not push an example, otherwise everyone could use that private key. It is not so important right now, but do you know what types of import addresses are not supported by Armory, which Core does support? And are there plans for the future to implement them? Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 08, 2017, 01:40:24 PM You mean compressed private keys?
Title: Re: 0.96.1 testing build #2 Post by: gangtraet on June 09, 2017, 01:46:30 PM That means there's some sort of compile error when compiling the Armory code. Are you following the build notes? (https://github.com/goatpig/BitcoinArmory/blob/dev/osxbuild/OSX_build_notes.md) If so, what's your setup? Yes, I am following the build nodes - more or less, at least. I have not downgraded Xcode as that would cause other problems for me. As I understand it, downgrading Xcode would be to build an app that also works on older versions of macOS. macOS 10.12.5 Xcode 8.3.3 Code: ~$ clang --version I have a good deal more installed with Homebrew than what is listed on the installation page. Code: ~$ brew list If the Armory build itself has failed, I would have expected that the build script terminated with an error, but of course things may go wrong in many ways. I will trawl through the log file, and see what I find. If I get time, I might try to build in a clean virtual machine, where I can follow the instructions to the letter without messing up my day job :) Title: Re: 0.96.1 testing build #2 Post by: droark on June 09, 2017, 08:46:02 PM That means there's some sort of compile error when compiling the Armory code. Are you following the build notes? (https://github.com/goatpig/BitcoinArmory/blob/dev/osxbuild/OSX_build_notes.md) If so, what's your setup? Yes, I am following the build nodes - more or less, at least. I have not downgraded Xcode as that would cause other problems for me. As I understand it, downgrading Xcode would be to build an app that also works on older versions of macOS. Sort of. It's perfectly fine to use older versions unless you absolutely must have access to a particular SDK or there's a bug you're trying to fix. In this case, the build target is OS X 10.7. Until I get the go-ahead to switch it to 10.8 (I believe goatpig wanted to ensure that older Mac users could get a version of Armory with SegWit support), users will have to swizzle the bits manually. The easiest thing to do is to go into the OS X build script and change the target version from 10.7 to 10.8. That should fix your issue. Title: Re: 0.96.1 testing build #2 Post by: walletrecoveryservices on June 10, 2017, 04:41:40 AM Hi. I have used Armory for years, and I really like it.! Thanks for maintaining it :)
The latest builds (since 0.96, and including this latest 0.96.02 test build), do not output the comments when the transaction lists are exported via the "Export Transactions" to CSV menu. For instance: 2014-Apr-21 12:58pm,9eb...,738339,3AznXg8eo,MyWallet (Watch),0.01,,, 0.01000000, 0.01000000,"" In previous versions, this was output as: 2014-Apr-21 12:58pm,9eb...,738339,3AznXg8eo,MyWallet (Watch),0.01,,, 0.01000000, 0.01000000,"InputTest" So you can see that the comment (which is still visible in the Armory UI) is missing from the Exported Transactions. Can you advise / fix? I really need this comment information to maintain my records of transactions... Thanks Dave Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 10, 2017, 01:02:43 PM Sounds like a bug, will look into it.
Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 11, 2017, 02:58:10 AM Hi. I have used Armory for years, and I really like it.! Thanks for maintaining it :) The latest builds (since 0.96, and including this latest 0.96.02 test build), do not output the comments when the transaction lists are exported via the "Export Transactions" to CSV menu. For instance: 2014-Apr-21 12:58pm,9eb...,738339,3AznXg8eo,MyWallet (Watch),0.01,,, 0.01000000, 0.01000000,"" In previous versions, this was output as: 2014-Apr-21 12:58pm,9eb...,738339,3AznXg8eo,MyWallet (Watch),0.01,,, 0.01000000, 0.01000000,"InputTest" So you can see that the comment (which is still visible in the Armory UI) is missing from the Exported Transactions. Can you advise / fix? I really need this comment information to maintain my records of transactions... Thanks Dave I can't reproduce. Are the missing comments address or tx comments? Address comments are created in the wallet properties dialog, tx comments are made in the main ledger. Title: Re: 0.96.1 testing build #2 Post by: Carlton Banks on June 11, 2017, 09:52:22 AM In this case, the build target is OS X 10.7. Until I get the go-ahead to switch it to 10.8 (I believe goatpig wanted to ensure that older Mac users could get a version of Armory with SegWit support) I'm fairly sure that 10.7 won't work with Core 13.0 and higher, as 10.7 doesn't have C++11. Title: Re: 0.96.1 testing build #2 Post by: gangtraet on June 11, 2017, 07:44:08 PM In this case, the build target is OS X 10.7. Until I get the go-ahead to switch it to 10.8 (I believe goatpig wanted to ensure that older Mac users could get a version of Armory with SegWit support), users will have to swizzle the bits manually. The easiest thing to do is to go into the OS X build script and change the target version from 10.7 to 10.8. That should fix your issue. I tried it, unfortunately the build still fails the same way. I found this in the build log: Code: ******************************************************************************** and this a bit later: Code: ******************************************************************************** Title: Re: 0.96.1 testing build #2 Post by: droark on June 12, 2017, 07:23:34 AM In this case, the build target is OS X 10.7. Until I get the go-ahead to switch it to 10.8 (I believe goatpig wanted to ensure that older Mac users could get a version of Armory with SegWit support), users will have to swizzle the bits manually. The easiest thing to do is to go into the OS X build script and change the target version from 10.7 to 10.8. That should fix your issue. I tried it, unfortunately the build still fails the same way. Try doing this manually in the OS X root directory. Code: git submodule init I don't know why this isn't done automatically but it seems to be required on OS X at least. Title: Re: 0.96.1 testing build #2 Post by: gangtraet on June 12, 2017, 07:49:19 AM Code: git submodule init Should have worked that one out myself :) I really like git, but the submodule stuff is so user-unfriendly that I decided to do something else in one of my own projects (a bit more work for me, but people who clone it have a chance). I also pulled from the testing branch, probably shouldn't have done that, as I get a crash much earlier: Code: ******************************************************************************** But you probably should not waste time helping me with this. Goatpig has released 0.96.0.2 last week with an OSX build (thank you !!!), I will try that tonight. Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 12, 2017, 02:58:01 PM Should have worked that one out myself :) I really like git, but the submodule stuff is so user-unfriendly that I decided to do something else in one of my own projects (a bit more work for me, but people who clone it have a chance). That turned out to be much worse than what I had expected. I'll prolly move to git subtree instead. Title: Re: 0.96.1 testing build #2 Post by: gangtraet on June 12, 2017, 06:50:29 PM I have now tested the new testing build on macOS X 10.12.5.
The good news is that it runs, and the few features I have tested work as expected. The bad news is that you are going to get a lot of posts from frustrated users who cannot start the app: It looks like if you unzip the application, you cannot run it until you have manually moved the app bundle to another folder ! I am 99% sure it is App Translocation, a new security feature in macOS which causes this as a side effect. App Translocation prevents some forms of attacks to some type of apps by copying the entire app into a disk image which is then made read-only. Then the app is executed from within this disk image. Once an app is moved with the Finder (but not with mv) then App Translocation is disabled for the app, since moving it prevents the kind of attacks App Translocation was designed to protect against. So if you do not move Armory, it is executed from within a read-only disk image, in my case from this path: Code: /private/var/folders/cq/5k4g7j_j5q3crgmh_glgp8yr0000gn/T/AppTranslocation/75F2CD25-05E9-4AC8-A15C-98AEE371C58F/d/Armory.app/Contents/MacOS Why would that matter? After all, Armory does not care from where it is executed? Well, the problem is that this disk image is read-only, and the first time Armory starts it makes a softlink inside itself. That fails if the disk image is read-only, and then the Armory startup script cannot execute Python! Code: # OS X has a quirk. For whatever reasons, if you execute Python from a different Symptoms:
Info about App Translocation: http://lapcatsoftware.com/articles/app-translocation.html and more detailed, including a similar case to what we see with Armory: https://www.synack.com/2016/12/16/untranslocating-apps/ Recommendation: Since the softlink inside the app is internal, it could be made when the app is build instead of as a workaround when running it. Then App Translocation will not matter. Title: Re: 0.96.1 testing build #2 Post by: gangtraet on June 12, 2017, 07:03:23 PM One small usage problem. If I exit Armory, I need to wait a minute or so before starting it again, otherwise it fails to start. It is not ArmoryDB running, it has already stopped. I see this in the log:
Code: 2017-06-12 20:59:38 (INFO) -- ArmoryUtils.py:1689 - C++ block utilities loaded successfully Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 12, 2017, 07:45:12 PM That's the process mutex, suggesting the listen socket on the previous client has not been closed yet. You toy with it here, figure out what's going on:
https://github.com/goatpig/BitcoinArmory/blob/testing/cppForSwig/SwigClient.cpp#L1065 Title: Re: 0.96.1 testing build #2 Post by: creamers on June 12, 2017, 08:41:37 PM Bug ?
I have two wallets, one native and one cold wallet. When Filter is set to "all wallets" and I double click on Comments in that particular colomn, paste the text and press oke , the Filter will jump to My Wallets automatically.... imo it should stay at the same filter settings. Title: Re: 0.96.1 testing build #2 Post by: goatpig on June 12, 2017, 08:58:40 PM Post armorylog.txt
Title: Re: 0.96.1 testing build #2 Post by: creamers on June 13, 2017, 08:33:27 AM I cleared the log, then started armory and did what I described earlier. (add a comment and then the filter switches to my wallet when it was set on all wallets)
https://pastebin.com/Gxqr5nZ6 (https://pastebin.com/Gxqr5nZ6) I think this is some sort of gui bug thingy ? : http://imgur.com/a/ECgRQ Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 14, 2017, 04:34:00 PM Bumping for the new testing builds.
Title: Re: 0.96.1 testing build #3 Post by: creamers on June 14, 2017, 04:43:30 PM Nice! ( https://github.com/goatpig/BitcoinArmory/commit/eb826b671155eb57fe7271c8d140431ebe8b8bbc )
Will test some more. *EDIT First time Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 14, 2017, 04:48:32 PM If the bug is still there, you gonna have to try and narrow it down. It didn't happen anymore in my testing after the fix.
Title: Re: 0.96.1 testing build #3 Post by: creamers on June 14, 2017, 05:57:44 PM Found the problem.
I have two wallets. One watch only wallet en one native wallet. When I open Armory it defaults to "My Wallets" showing both wallets !! (Think this is already wrong as it should not show the WatchOnly wallet.) Changing a comment activates the Filter, meaning, it then becomes active and the WatchOnly wallet disappears because it doesnt belong in the filter view My Wallets. It's either case, the watch only wallet should be visible in 'my wallets' OR the filter should become active at startup and not only when comments are changed. I think it should be set to All Wallets at startup showing all wallets. Problem solved ;) Hope it helps, otherwise let me know. (ps, I noticed alot more crashes at closing but will investigate / narrow it down) Title: Re: 0.96.1 testing build #3 Post by: creamers on June 14, 2017, 06:35:06 PM see previous post about Filter.
Now about the crashes...it seems to crash while it was running oke....now happened several times. Code: 2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1135 - C++ block utilities loaded successfully Code: -WARN - 20:22:40.241: (..\BDM_supportClasses.cpp:1898) running 2285 zc parser threads Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 14, 2017, 09:55:34 PM Code: running 2340 zc parser threads This is a relevant symptom. How large is your node's mempool? Anything worth of note getting to that point? Let the Armory run for a few hours, does it get to that point? Quote (Think this is already wrong as it should not show the WatchOnly wallet.) ... It's either case, the watch only wallet should be visible in 'my wallets' Which one is it? WO's can be considered your wallet as long as you specify that in the ownership field. They are not by default however. Title: Re: 0.96.1 testing build #3 Post by: idoB on June 15, 2017, 04:45:50 PM I can confirm the bug preventing use of fragmented backups is fixed. THANKS!
On the down side, the bug exporting key list reported here: https://bitcointalk.org/index.php?topic=1957569.0 (https://bitcointalk.org/index.php?topic=1957569.0) still there in 96.1.0.3 (same error in log). Log: Code: (ERROR) -- Traceback (most recent call last): Title: Re: 0.96.1 testing build #3 Post by: creamers on June 15, 2017, 08:00:57 PM Code: running 2340 zc parser threads This is a relevant symptom. How large is your node's mempool? Anything worth of note getting to that point? Let the Armory run for a few hours, does it get to that point? Taskmanager: https://s16.postimg.org/6gctny42t/taskmanager.png It's running fine untill it crashes. .2 test version didnt do that. Cleared the log files and started it again. Here they are: armory log: https://pastebin.com/TiWpt0yr (https://pastebin.com/TiWpt0yr) dblog: https://pastebin.com/DFJ7TrBc (https://pastebin.com/DFJ7TrBc) Which one is it? WO's can be considered your wallet as long as you specify that in the ownership field. They are not by default however. Let me rephrase, I have two wallets, one mine and one not mine. When I start armory the filter is default to MyWallets setting but it's showing ALL wallets until I change something in the comments fields, then it will show only My Wallets and thus showing one wallet in my case. (If armory start defaulting to My Wallets then it should only show my wallets and not all of them.) Title: Re: 0.96.1 testing build #3 Post by: creamers on June 16, 2017, 10:30:43 AM and again:
Cleared the logs first and started armory...I just let it run (with bitcoind in background) and it crashed: dblog: https://pastebin.com/cfNL4WBM armorylog: https://pastebin.com/ixRCKe2t Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 16, 2017, 02:14:58 PM Pushed a fix for that
Title: Re: 0.96.1 testing build #3 Post by: creamers on June 16, 2017, 04:54:52 PM oke, will have to wait for the build to test it out.
*EDIT: since I started without the bitcoind and with bitcoin core in the foreground it runs without crashes. Title: Re: 0.96.1 testing build #3 Post by: Mr.Vice on June 19, 2017, 02:33:50 PM Bug Report: Armory 0.96.0.3-testing
------------------------------------------------------------------------------------------------------------------------------------------------------------------------- BUG #1 Offline Transactions > Sign/Broadcast transaction > Load file ... The file loading function in Offline Transactions seem to be broken. In order to load the file you have to open the .tx files with the notepad and copy/paste the text. *** PROBABLY SOLVED: (.TX) DATA WITH 0.96.0.2 CREATED *** armorylog.txt Code: 2017-06-19 16:15:25 (ERROR) -- qtdialogs.pyc:5836 - Error showing TxOut ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- BUG #2 Select Offline Wallet > Send > Open address book > Select address This button is also still broken (like double-click). Addresses can only be chosen via the address book by right-click copy address and paste it into the address field in the sending dialoge. armorylog.txt Code: 2017-06-19 16:36:41 (ERROR) -- Traceback (most recent call last): BUG #3 Right-click tx in global ledger (main window) > Select "bump fee" This function (menu button) also seems to be broken. When you click on it, nothing happens (like Bug #1). *** PROBABLY SOLVED: INSUFFICIENT FUNDING (MAX. INPUT SPENDING) *** armorylog.txt Code: 2017-06-19 19:24:43 (ERROR) -- Traceback (most recent call last): Kind regards :-) Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 25, 2017, 08:21:46 AM Will there be offline bundles for the next release? If I setup a new offline wallet should I use 0.96 or one of the latest test versions or wait for 0.96.1 (approx release date?:))?
I used to have ubuntu 12 on my offline wallet but some altcoins wallets require a more up to date system. My plan is to create the dependency files on my own when I run the ubuntu 16 live cd on an online machine and install armory. All packages should then be in /var/cache/apt/archives/ and can be copied to the same folder on the offline machine that runs the same fresh ubuntu install. "sudo dpkg -i /var/cache/apt/archives/*deb" should install the packages. Maybe it's useful for someone. The mac binary of the latest test version is not starting. I filled an issue: https://github.com/goatpig/BitcoinArmory/issues/253 Thanks for all the work goatpig. Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 25, 2017, 08:29:16 AM Will there be offline bundles for the next release? Yes Quote If I setup a new offline wallet should I use 0.96 or one of the latest test versions or wait for 0.96.1 (approx release date?Smiley)? If your online system is weak, wait for 0.96.1. Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 26, 2017, 07:31:49 AM The mac binary of the latest test version is not starting. I filled an issue: https://github.com/goatpig/BitcoinArmory/issues/253 I just checked the Application Support dir of Armory but no log files were created for that crash. Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 26, 2017, 07:32:41 AM Ask droark, he takes care of the OSX stuff.
Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 26, 2017, 10:27:02 AM Ask droark, he takes care of the OSX stuff. Okay, I sent him a msg. When I started Armory in the console it printed this error msg: BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py': [Errno 2] No such file or directory Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 26, 2017, 10:30:35 AM There was a post some weeks ago in this thread where someone pointed out something about the newest OSX giving you grief if you don't move the scripts around on your system (for whatever reason). You should try and dig that out.
Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 26, 2017, 07:55:24 PM I was digging to the whole thread to find some solution but couldn't come up with anything that worked for me on Mac OS 10.12.5.
I moved the binary to another folder/applications but Armory still doesn't start. I tried to compile with Code: minOSXVer = '10.8' Starting Armory by command line within the .app package returns Code: Armory.app/Contents/MacOS/Python: can't open file '/Applications/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py': [Errno 2] No such file or directory executing Code: git submodule init in "osxbuild" as suggested in this thread and building it again leads to the same problem.... ??? ??? ??? :'( according to my build log the error msg are similar to the ones gangtraet got. Code: 1 error generated. Seems there are really some files missing in my compiled mac binary. It's only about 108MB while the binary from the latest releases is around 150mb. Unfortunately the binaries from the latest release are also not working for me. Code: Termination Signal: Illegal instruction: 4 Title: Re: 0.96.1 testing build #3 Post by: gangtraet on June 27, 2017, 08:09:51 AM I was digging to the whole thread to find some solution but couldn't come up with anything that worked for me on Mac OS 10.12.5. It may be my post he is referring to. You need to move Armory.app using the Finder before you can use it. If it has never been moved since it was unpacked (or was moved using mv), OS X enables some hacking protection called App Translocation, and that unfortunately breaks Armory (although a simple workaround could be enable at build time). See https://bitcointalk.org/index.php?topic=1917955.msg19519942#msg19519942 Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 27, 2017, 08:49:50 AM I was digging to the whole thread to find some solution but couldn't come up with anything that worked for me on Mac OS 10.12.5. It may be my post he is referring to. You need to move Armory.app using the Finder before you can use it. If it has never been moved since it was unpacked (or was moved using mv), OS X enables some hacking protection called App Translocation, and that unfortunately breaks Armory (although a simple workaround could be enable at build time). See https://bitcointalk.org/index.php?topic=1917955.msg19519942#msg19519942 I moved my Armory.app package around several times with finder but it didn't help :( My exact steps: - unpack tar.gz package - move Armory.app to another folder - start Armory.app - OS X warning pops up that file is not from a certified developer. - I go to system settings -> security -> click "open" -> confirm that I want to open Armory - Armory symbol starts to jump around in dock but after some seconds it disappears again - Armory Bitcoin Client crashed window pops up (same msg as posted before) Title: Re: 0.96.1 testing build #3 Post by: gangtraet on June 27, 2017, 09:17:04 AM Try opening a Terminal, and go to the folder where Armory.app is. Then start it with this command line:
Code: Armory.app/Contents/MacOS/Armory Cut-and-paste any errors to this thread. Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 27, 2017, 09:21:19 AM Code: MacBook-Pro:Desktop myusername$ Armory.app/Contents/MacOS/Armory Then Mac OS crash report opens. I pm'ed you the full report. Title: Re: 0.96.1 testing build #3 Post by: gangtraet on June 27, 2017, 09:34:15 AM Ouch! I cannot really read the crash report, but I notice this part:
Code: Exception Type: EXC_BAD_INSTRUCTION (SIGILL) To me, it looks like your Mac is somewhat old, and that the executable is built assuming a newer CPU. I don't know how to proceed from here, perhaps the developers can help you. I guess you can attempt to build Armory.app yourself, I did not have any success doing so myself, but you could try following the instructions here: https://github.com/goatpig/BitcoinArmory/blob/master/osxbuild/OSX_build_notes.md It might, however, be a good idea to wait until goatpig and co come online and reply in this thread, they may have better ideas. Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 27, 2017, 09:36:49 AM Thanks for your help.
I already tried to compile it by myself. Compiling works but the app package does not start as well but with a different error message (ArmoryQt.Py is missing) and the binary is about 50mb smaller than the one from the github release. My Mac is from Mid 2012, Intel Core i5, 2,5 GHz. For reference the first lines of the crash report Code: Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Code: Binary Images: Maybe it's related to this issue: https://stackoverflow.com/questions/38167803/genymotion-crash-on-start-in-osx Title: Re: 0.96.1 testing build #3 Post by: gangtraet on June 27, 2017, 09:50:00 AM I already tried to compile it by myself. Compiling works but the app package does not start as well but with a different error message (ArmoryQt.Py is missing) and the binary is about 50mb smaller than the one from the github release. My Mac is from Mid 2012, Intel Core i5, 2,5 GHz. I had the same problem. I think it is related to something missing from the source code package that github generates. Maybe if you get the source code like this: Make sure you are in a folder without an old BitcoinArmory source folder in it, then run Code: git clone https://github.com/goatpig/BitcoinArmory.git EDIT: spelling. Title: Re: 0.96.1 testing build #3 Post by: Tmptmpbuggyguy on June 27, 2017, 09:55:00 AM Quote Make sure you are in a folder without an old BitcoinArmory source folder in it, then run Code: git clone https://github.com/goatpig/BitcoinArmory.git Edit: Should the git commands not be executed from the osxbuild dir? Try doing this manually in the OS X root directory. Code: git submodule init (of course I used 'git' instead of 'dit') I tried it from the osxdir and with testing branch but no success (Mac OS Sierra 12.2.5, Xcode 8 ). Update: I made progress. I executed the git commands from the root dir of the source (like gangtraet suggested) and compiled: - The before missing ArmoryQt.py etc. files are included now :-) - Starting Armory from terminal prints: Code: Traceback (most recent call last): Update 2 Yippie! My build works. My quick fix was to replace libpng from the app bundle (v1.6.28) with the one from my system (v1.6.29) (you can get it with brew install libpng). Code: cp /usr/local/Cellar/libpng/1.6.29/lib/libpng16.16.dylib ~/Desktop/Armory.app/Contents/Dependencies/libpng16.16.dylib Updating the version number in build-app.py should do the job too. Hope this has not any negative side effects. Title: Re: 0.96.1 testing build #3 Post by: naska21 on June 27, 2017, 12:23:13 PM @goatpig, Hi, , just upgraded my off-line Armory from 0.93.3 to 0.96.03-testing version/ Everything vent smoothly but when I did Tools==> MessageSigning/Verification==> click select from Address Book to choose address for signing message the error window appears with the message " ArmoryQT.exe has stopped working "/ Repeated this a few times with the same result. The log is pasterbined https://pastebin.com/raw/juPni66G
Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 27, 2017, 12:56:12 PM Thanks for the report, will look into it.
Title: Re: 0.96.1 testing build #3 Post by: Casimir1904 on June 27, 2017, 01:38:07 PM Thanks for the report, will look into it. Help -> About doesn't work either. Didn't check all menu entries. Code: arg(self, QString, QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType' Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 27, 2017, 04:54:15 PM Thanks for the report, will look into it. Help -> About doesn't work either. Didn't check all menu entries. Code: arg(self, QString, QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType' Can't reproduce. Is this 0.96 or the testing branch? Can you show me the line # as well? Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 27, 2017, 04:56:16 PM @goatpig, Hi, , just upgraded my off-line Armory from 0.93.3 to 0.96.03-testing version/ Everything vent smoothly but when I did Tools==> MessageSigning/Verification==> click select from Address Book to choose address for signing message the error window appears with the message " ArmoryQT.exe has stopped working "/ Repeated this a few times with the same result. The log is pasterbined https://pastebin.com/raw/juPni66G Can't reproduce this either. Can you detail the steps you take? Title: Re: 0.96.1 testing build #3 Post by: naska21 on June 27, 2017, 05:11:01 PM @goatpig, Hi, , just upgraded my off-line Armory from 0.93.3 to 0.96.03-testing version/ Everything vent smoothly but when I did Tools==> MessageSigning/Verification==> click select from Address Book to choose address for signing message the error window appears with the message " ArmoryQT.exe has stopped working "/ Repeated this a few times with the same result. The log is pasterbined https://pastebin.com/raw/juPni66G Can't reproduce this either. Can you detail the steps you take? Step-by-step: Tools==> click Message Signing/... ==> mouse pointer on Book icon ( right near sign with Address:) and click on it ==> error window Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 27, 2017, 05:13:23 PM @goatpig, Hi, , just upgraded my off-line Armory from 0.93.3 to 0.96.03-testing version/ Everything vent smoothly but when I did Tools==> MessageSigning/Verification==> click select from Address Book to choose address for signing message the error window appears with the message " ArmoryQT.exe has stopped working "/ Repeated this a few times with the same result. The log is pasterbined https://pastebin.com/raw/juPni66G Can't reproduce this either. Can you detail the steps you take? Step-by-step: Tools==> click Message Signing/... ==> mouse pointer on Book icon ( right near sign with Address:) and click on it ==> error window Nvm, figured it out. Wasn't running in offline mode. Title: Re: 0.96.1 testing build #3 Post by: Casimir1904 on June 27, 2017, 06:36:34 PM Thanks for the report, will look into it. Help -> About doesn't work either. Didn't check all menu entries. Code: arg(self, QString, QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType' Can't reproduce. Is this 0.96 or the testing branch? Can you show me the line # as well? Yes testing branch Code: Traceback (most recent call last): Edit: building from your newest pushes gives: ./configure: line 18156: syntax error near unexpected token `fi' Code: else Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 28, 2017, 03:43:10 AM Both fixed now.
Title: Re: 0.96.1 testing build #3 Post by: naska21 on June 28, 2017, 07:28:42 AM Both fixed now. fixed in what release? Should we download again 0.96.0.3 - testing and install it on the top of the older one? Title: Re: 0.96.1 testing build #3 Post by: goatpig on June 28, 2017, 07:48:52 AM Fix is in the repo, no builds for it yet.
Title: Re: 0.96.1 testing build #3 Post by: Casimir1904 on June 28, 2017, 09:22:27 AM Both fixed now. Will pull later and report if i find other issues. Title: Re: 0.96.1 testing build #3 Post by: Stroto on July 04, 2017, 07:55:10 AM Hi, I'm using test build 3.
Today I wanted to send a tx but got the error message "Coin selection failed with error: failed to select utxos" Which is weird as I had no unconfirmed balances. Armory and Bitcoin Core are sync'd and displaying the same block number as any block explorer. When looking in the armory log i see no mention of that at all. I send it through different methods and that is the tx armory picks up. but no mention of the error. Code: 2017-07-04 09:11:50 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode For coin selection I tried: - first no special selection just make tx and send > error - second select the addresses with funds > error - third check "use all selected UTXOs" > error what did i do wrong and/or how can I prevent or solve this? Title: Re: 0.96.1 testing build #3 Post by: goatpig on July 04, 2017, 09:24:26 AM Is the fee bigger than what you are sending?
Title: Re: 0.96.1 testing build #3 Post by: Stroto on July 04, 2017, 12:14:40 PM Is the fee bigger than what you are sending? i set the fee sat/b how i wanted it too and pressed "max" after that. That particular wallet had 1 income tx a few days back so only one address used. So a small kb-wise tx I rechecked the tx i send through a different method. it looks like the fee that I set (select fee type > fee/byte) was too big (as in it exceeded the maximum funds) however i did press max after that. The only thing i can think of i did differently was putting the receiving address in after setting the fee and max. That might have caused it. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 04, 2017, 02:51:13 PM Testing builds #4 are out.
Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 05, 2017, 10:38:11 AM Try the latest builds.
Title: Re: 0.96.1 testing build #4 Post by: idoB on July 05, 2017, 05:20:52 PM I can confirm that the latest build, testing #4 solves the 'Export key list' error that I reported earlier (https://bitcointalk.org/index.php?topic=1957569.0 (https://bitcointalk.org/index.php?topic=1957569.0))
Thanks for that, goatpig! Title: Re: 0.96.1 testing build #4 Post by: wachtwoord on July 06, 2017, 12:34:35 PM I am still experiencing the memory leak problem where scanning the transactions takes a very long time. I ran it for 12 hours and it was at 4%, 1.5 month to go when I killed it. Is it helpful to let it run further?
Do you prefer I post about this in my own thread again instead of here? (I chose here because it's directly related to the #4 testing build). Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 06, 2017, 12:44:25 PM I am still experiencing the memory leak problem where scanning the transactions takes a very long time. I ran it for 12 hours and it was at 4%, 1.5 month to go when I killed it. Is it helpful to let it run further? Do you prefer I post about this in my own thread again instead of here? (I chose here because it's directly related to the #4 testing build). Use your own thread, easier to track down. Title: Re: 0.96.1 testing build #4 Post by: naska21 on July 06, 2017, 01:17:52 PM Sorry, wrong info, everyrhing is OK with sha256sum.txt.asc. Just installed 0.96.0.4 and was very pleased to find that the bug previously reported by me (https://bitcointalk.org/index.php?topic=1917955.msg19800854#msg19800854) has been fixed in this build. Thanks, goatpig Title: Re: 0.96.1 testing build #4 Post by: paranoidx on July 06, 2017, 11:08:49 PM Armory .95 stopped working for me. Upgraded to .96.1 test 4.
Armory shows scanning transaction history for about 2-3 hours. It then shows 1 second remaining but never actually loads. Armory shows it is offline. I have Bitcoin Core 14.2 running in the background. It is fully synced. I am running on Linux Mint 17. https://pastebin.com/embed_js/Gi6U9k9i Title: Re: 0.96.1 testing build #4 Post by: paranoidx on July 07, 2017, 02:46:00 AM Rebuilt and rescanned database, it is now showing my balance and showing that it is connected.
I now get the following error when trying to send a transaction: "The transaction that you attempted to broadcast hast timed out." "The RPC interface in your node is disabled..." Title: Re: 0.96.1 testing build #4 Post by: paranoidx on July 07, 2017, 02:49:32 AM Okay it seems core wasnt running correctly in the background that 2nd time. All good now. I was able to send transaction.
Title: Re: 0.96.1 testing build #3 Post by: creamers on July 10, 2017, 05:59:44 AM oke, will have to wait for the build to test it out. *EDIT: since I started without the bitcoind and with bitcoin core in the foreground it runs without crashes. Since build #4 it is running stable again with bitcoind in the background. Thank you for your effort! Title: Re: 0.96.1 testing build #4 Post by: naska21 on July 10, 2017, 08:22:28 AM Hi, should we upgrade bitcoin-qt to 0.14.2 version to run alongside with the latest 0.96.1 testing build #4, and if YES, will it run smoothly?
Title: Re: 0.96.1 testing build #4 Post by: Tmptmpbuggyguy on July 10, 2017, 11:00:41 AM Armory 0.96.0.3 is stuck and says "Building databases ... 15 Minutes".
Quote -INFO - 1499683142: (DatabaseBuilder.cpp:268) parsed block file #248 -INFO - 1499683160: (DatabaseBuilder.cpp:268) parsed block file #252 -INFO - 1499683167: (SocketObject.cpp:350) POLLIN recv return 0 -ERROR - 1499683167: (BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread -INFO - 1499683167: (BitcoinP2P.cpp:969) Disconnected from Bitcoin node Restarting Armory leads to "Building databases ... 48 Minutes" (not stuck). Quote -WARN - 1499684451: (BDM_supportClasses.cpp:1891) running 0 zc parser threads -WARN - 1499684451: (BDM_supportClasses.cpp:1891) running 5 zc parser threads -WARN - 1499684451: (BDM_supportClasses.cpp:1891) running 10 zc parser threads -WARN - 1499684451: (BDM_supportClasses.cpp:1891) running 15 zc parser threads -WARN - 1499684468: (BDM_supportClasses.cpp:1891) running 20 zc parser threads -WARN - 1499684468: (BDM_supportClasses.cpp:1891) running 25 zc parser threads -WARN - 1499684468: (BDM_supportClasses.cpp:1891) running 30 zc parser threads -WARN - 1499684468: (BDM_supportClasses.cpp:1891) running 35 zc parser threads -INFO - 1499684482: (DatabaseBuilder.cpp:169) Reading headers from db -WARN - 1499684482: (lmdb_wrapper.cpp:1175) No headers in DB yet! -INFO - 1499684482: (DatabaseBuilder.cpp:208) Found 1 headers in db -INFO - 1499684482: (DatabaseBuilder.cpp:51) updating HEADERS db -INFO - 1499684487: (DatabaseBuilder.cpp:268) parsed block file #1 -INFO - 1499684488: (DatabaseBuilder.cpp:268) parsed block file #2 -INFO - 1499684494: (DatabaseBuilder.cpp:268) parsed block file #3 Some time later Quote (ERROR) ArmoryQt.py:1188 - 3 attempts to load blockchain failed. Remove mempool.bin. (ERROR) ArmoryQt.py:1193 - File mempool.bin does not exist. Nothing deleted. Restarted Armory Quote -INFO - 1499691206: (DatabaseBuilder.cpp:268) parsed block file #33 -INFO - 1499691222: (DatabaseBuilder.cpp:268) parsed block file #34 -INFO - 1499691223: (DatabaseBuilder.cpp:268) parsed block file #35 -INFO - 1499691223: (DatabaseBuilder.cpp:268) parsed block file #37 -INFO - 1499691230: (DatabaseBuilder.cpp:268) parsed block file #38 -INFO - 1499691233: (DatabaseBuilder.cpp:268) parsed block file #39 I'm able to build the 0.96.0.4 on Mac OS but the final binary lacks of some files as mentioned earlier in this thread and is not starting. I'll try again now. In the recent time it always takes me several hours to move funds from cold storage :/ (don't have a SSD). Title: Re: 0.96.1 testing build #4 Post by: Tmptmpbuggyguy on July 10, 2017, 08:39:28 PM I'm still not able to get a working build of the OS X version > Armory 0.96.0.
Quote can't open file '/Users/user/Desktop/Armory0.9.6.0.4-testing/osxbuild/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py': I followed all suggestions from this thread and also updated the mac os version to 10.8 in the build script. I also tried the git submodule stuff. The last provided testing build binary works not for me because it uses some CPU instructions that my hardware does not support. Title: Re: 0.96.1 testing build #4 Post by: XCTfluid on July 11, 2017, 12:28:03 PM Is there change log for test builds? Just can't find it now. Anyway not big deal, just curious.
Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 11, 2017, 01:02:30 PM Hi, should we upgrade bitcoin-qt to 0.14.2 version to run alongside with the latest 0.96.1 testing build #4, and if YES, will it run smoothly? You can update to 0.14.2 I'm still not able to get a working build of the OS X version > Armory 0.96.0. .tag 0.96.0.4 is broken on OSX. That's been in testing but testing is broken atm for other reasons, so you'll have to wait. Quote The last provided testing build binary works not for me because it uses some CPU instructions that my hardware does not support. That shouldn't not matter, none of these ASM optimizations are enabled on the OSX builds. Is there change log for test builds? Just can't find it now. Anyway not big deal, just curious. The changelog in testing, but I have not updated it in a while. Crawl the commit history comments if you want to get an idea. Title: Re: 0.96.1 testing build #4 Post by: Tmptmpbuggyguy on July 11, 2017, 01:07:46 PM OK thanks goatpig. Meanwhile I try to get my 0.96 working again.
Quote -DEBUG - 1499774917: (Blockchain.cpp:242) Organizing chain The log is already since some time like this and in "preparing database state". Does it mean armory is still working or should I restart?-INFO - 1499775031: (DatabaseBuilder.cpp:56) updated HEADERS db in 6514s -INFO - 1499775032: (BlockUtils.cpp:1206) Enabling zero-conf tracking Updat I checked the Armory processes with my task manager and ArmoryDB was like idle so I gave a restart a try and now it says building db :) Quote The last provided testing build binary works not for me because it uses some CPU instructions that my hardware does not support. That shouldn't not matter, none of these ASM optimizations are enabled on the OSX builds. I assumed that cause when I started the 0.96 osx binary it said illegal instruction but building on my own worked fine. Maybe a dependency is using such instructions !?!? Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 11, 2017, 03:19:39 PM I assumed that cause when I started the 0.96 osx binary it said illegal instruction but building on my own worked fine. Maybe a dependency is using such instructions !?!? https://github.com/goatpig/BitcoinArmory/blob/testing/cppForSwig/cryptopp/Makefile.am#L15 That stuff is completely disabled on OSX. This ought to be something else. Building yourself is always preferable at any rate, autotools should make that more accessible. Title: Re: 0.96.1 testing build #4 Post by: gangtraet on July 13, 2017, 06:35:31 AM Failed to build on Raspberry Pi
Hi, I tried to build v0.96.0.4 on a Raspberry Pi (the git tag is v0.96.0.4 not v0.96.0.4-testing as for the other testing releases, right?). After four hours, compilation fails. It looks like it is caused by "long long unsigned int" being different from "long unsigned int", see this paste: https://pastebin.com/xckJrHte Some version numbers: Autoconf 2.64 Automake 1.14.1 Libtool 2.4.2 gcc/g++ 4.9.2-10 swig 2.0.12 Rasbian 8 (the newest) based on jessie. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 13, 2017, 10:09:03 AM You do not build on RPi. You cross compiled from a Linux machine:
https://github.com/goatpig/BitcoinArmory/blob/master/r-pi/README.md Title: Re: 0.96.1 testing build #4 Post by: gangtraet on July 13, 2017, 12:11:27 PM You do not build on RPi. You cross compiled from a Linux machine: OK, that is undoubtedly faster :) I just felt it was better that the RPi spent 8 hours compiling than I spent 4 hours figuring out how to cross compile. But I will do that now! Thanks Title: Re: 0.96.1 testing build #4 Post by: gangtraet on July 13, 2017, 03:20:47 PM You do not build on RPi. You cross compiled from a Linux machine: https://github.com/goatpig/BitcoinArmory/blob/master/r-pi/README.md Unfortunately, that didn't work either. The configure script complains about No assembler code for CPU arm, and later Make fails because there was not Makefile in cryptopp. Title: Re: 0.96.1 testing build #4 Post by: creamers on July 17, 2017, 06:40:37 PM While trying to create a unsigned transaction I notice this:
https://www.screencast.com/t/2hhmT0R9o Fee rate per node is set to 197 sat/byte and it gave me a warning, so I wanted to change this and set it to Fee/Byte (Satoshi/Byte) and wanted to set it to 200. Now it seems that it doesnt change as soon as I go above 197 in the Fee/Byte field. (In above movie is recorded) Is this a bug or why can't I set a higher "Fee/Byte" than the current "Fee Rate per Node" ? http://i66.tinypic.com/23tgzzl.png Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 17, 2017, 07:31:48 PM I don't have Flash installed so I can't watch this video.
Title: Re: 0.96.1 testing build #4 Post by: creamers on July 17, 2017, 08:39:08 PM You can see it in the picture.....typed 200, but it only says 20.
As soon as I type anything <=197 is shows the correct value, otherwise like in the picture. *edit I see that it didnt max the spendable amount cause I edited the fee. The button should be pressed automatically again when the fee is changed imo Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 18, 2017, 12:42:28 PM You can see it in the picture.....typed 200, but it only says 20. As soon as I type anything <=197 is shows the correct value, otherwise like in the picture. *edit I see that it didnt max the spendable amount cause I edited the fee. The button should be pressed automatically again when the fee is changed imo I've replied to this already. The idea was that I wouldn't have to spend 2 days figuring this out because users could spend the extra second to press the "MAX" button once again, seeing it's a button and not a check box, therefor realizing the semantics indicate the functionality is not biding, and that it has always been this way since the MAX button was introduced. Title: Re: 0.96.1 testing build #4 Post by: Mr.Vice on July 19, 2017, 08:38:01 AM Hey goatpig!
I've tested the new build "Armory 0.96.0.4-testing". I'm recalling on the address book issue - BUG #1 - (address selection via "select address" button). There is also an major issue with Bug #2 (see beneath). Altough the offline tx file loading bug has now been solved with this version! ------------------------------------------------------------------------------------------------------------------------------------------------ BUG #1 Select Wallet > Send > Open address book > Select address This button is also still broken (like double-click). Addresses can only be chosen via the address book by right-click copy address and paste it into the address field in the sending dialoge. armorylog.txt Code: 2017-07-19 09:31:00 (ERROR) -- Traceback (most recent call last): ------------------------------------------------------------------------------------------------------------------------------------------------ BUG #2 Executing ArmoryQt > The first progress bar isn't displayed (ArmoryDB takes a little bit longer to initialize) > Armory has now started ArmoryDB and grabs existing block data > Armory loaded but isn't able to connect to bitcoind This issue occurs from time to time and the only solution is to restart the PC and then start ArmoryQt again after reboot. But after this I get very often POLLER Errors and "raw blockchain data doesn't match expected block hash" Errors. So I need to to Rebuild & Rescan. I have no AV installed and Windows Defender already has exceptions for every Program associated with Armory and Bitcoin Core. So I have no clue why this happens again. dbLog.txt (No.1) Code: -INFO - 09:21:45.047: (..\lmdb_wrapper.cpp:388) Opening databases... dbLog.txt (No.2) Code: -INFO - 09:45:43.125: (..\lmdb_wrapper.cpp:388) Opening databases... Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 19, 2017, 10:36:19 AM BUG #1:
Cannot reproduce, never was able to. What locale are you using? BUG #2: Do not use auto bitcoind. Also build the current state of testing. Title: Re: 0.96.1 testing build #4 Post by: Mr.Vice on July 25, 2017, 01:30:47 PM BUG #1: Cannot reproduce, never was able to. What locale are you using? BUG #2: Do not use auto bitcoind. Also build the current state of testing. Regarding Bug #1: I'm using the german locale [Deutsch (de)]. Bug #2: I've completed a rebuild & rescan with some block deser errors, but managed to run through anyway. So it seems to work now, but with build #3. I'm going to test build #4 on another machine seperatly. Kind regards :-) Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 25, 2017, 03:10:30 PM Regarding Bug #1: I'm using the german locale [Deutsch (de)]. Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue. Title: Re: 0.96.1 testing build #4 Post by: gangtraet on July 25, 2017, 08:41:16 PM Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue. Ouch! It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment. Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 25, 2017, 10:00:07 PM Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue. Ouch! It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment. Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption. That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail. My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code. Title: Re: 0.96.1 testing build #4 Post by: Mr.Vice on July 26, 2017, 10:38:57 AM Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue. Ouch! It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment. Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption. That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail. My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code. I've found one folder I'd been using for storing unsigned transactions, in order to use them over different local user accounts. The folder is called "Öffentlich" in german, although Windows works with given folder names in english in the background anyway. But it seem I've called another folder "Öffentlich ..." in that same dir that was custom. So I've renamed it to "Oeffentlich". Wallet didn't seem to be affected by this, since Armory couldn't find any errors and when I try to enter a non-ascii characted in any label I automatically receive an error prompt message. What's more problematic are the custom folders, because for e.g. in german you have many characters which are not ascii compatible. Another question regarding RPC. Why does Armory display in auto-managed bitcoind that RPC is disabled? Since .1 or .2 of the testing builds I get that tool-tip when hovering over that block count? I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple? Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 26, 2017, 01:08:15 PM Quote Another question regarding RPC. Why does Armory display in auto-managed bitcoind that RPC is disabled? Since .1 or .2 of the testing builds I get that tool-tip when hovering over that block count? I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple? I'd have to look into it. Title: Re: 0.96.1 testing build #4 Post by: alomar on July 27, 2017, 10:32:18 PM i didn't get an answer to this in the other thread so i thought i'd post it here:
is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751? everything else appears ok. getblockcount shows correct height. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 27, 2017, 10:36:49 PM i didn't get an answer to this in the other thread so i thought i'd post it here: is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751? everything else appears ok. getblockcount shows correct height. Connected only means the DB is connected to a node over the P2P layer. The block height is what your DB sees as the longest chain. If it's behind your node, your DB has an issue. Try 0.96.0.4, it fixes a lot of that stuff. Title: Re: 0.96.1 testing build #4 Post by: WiiD on July 27, 2017, 10:54:50 PM I use 0.96.0.4 and cannot access my BTCs since then.
ArmoryDB.exe always crashes at "Scanning Transaction History" at 98 or 99%. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 27, 2017, 10:57:56 PM logs
Title: Re: 0.96.1 testing build #4 Post by: WiiD on July 27, 2017, 11:36:37 PM Where do I find them?
Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 27, 2017, 11:55:57 PM https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockDataManagerConfig.cpp#L32
Title: Re: 0.96.1 testing build #4 Post by: WiiD on July 29, 2017, 02:10:55 PM https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockDataManagerConfig.cpp#L32 I do not understand what I do with this? I just upgraded to 0.96.1 from the newest sticked thread, same problem. ArmoryDB.exe always crashes at "Scanning Transaction History" , I am not able to access my BTCs since weeks and that is much money.. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 29, 2017, 02:39:33 PM Code: const string BlockDataManagerConfig::defaultDataDir_ = This is where you find your logs. Otherwise extract them from the file menu option. Title: Re: 0.96.1 testing build #4 Post by: WiiD on July 29, 2017, 04:11:55 PM http://pastebin.ca/3848861
Title: Re: 0.96.1 testing build #4 Post by: WiiD on July 30, 2017, 01:03:39 PM http://pastebin.ca/3848861 Please help me, I need to access my BTCs, it is all my money. Title: Re: 0.96.1 testing build #4 Post by: goatpig on July 30, 2017, 01:51:02 PM I can't do this here, it's too much of a pain to crawl back through history to figure out what's going on. This is why you don't hijack a thread to ask for help. Make your own.
Title: Re: 0.96.1 testing build #4 Post by: Holliday on July 30, 2017, 04:14:42 PM Please help me, I need to access my BTCs, it is all my money. Extract your private keys and import them into a wallet that is easier to use (and less secure). |