0.96.1 testing build #4

[goatpig]

Third testing builds are out.

------------------

Binaries:
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4

Fixes/Changes:

Code:

v0.96.1

== Added ==
   - Split unit tests building from default autotools setup. To build tests, use:
      ./configure --enable-tests.
   - You can now disable GUI in the autotools build system. Use: 
      ./configure --without-gui
   - When spawned with a cookie file, the DB now randomizes its listen port to (49150 + [0-15000]) and reports it in the cookie file.
   - Added --fcgi-port command line argument to the DB.

== Fixed ==
   - ZC parsing will no long occur while the BDM is initializing
   - Wait on cookie file creation before connection to auto managed DB
   - Fixed registration/callback premature garbage collection
   - Translation patch issues
   - Fixed "Fund from wallet" lockbox GUI
   - Fixed TxIn/Out pretty printing
   - Tied init phase spinning icon rotation to progress notifications. The icon will not spin when no progress data is received, correctly 
     indicating the DB is hanging.   
   - Fixed cryptopp build against older CPUs (no AES or PCLMUL archs)
   - Fixed RBF bumping with no change

== Removed ==
   - Python-twisted dependency. This should remove the underlying openSSL dependency as well.

--------------

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.

[1714193086]

1714193086

[Mr.Vice]

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.

[ask]

Now works fine. Thank you!

[gangtraet]

Does it make sense to attempt a build on my Macbook?

If so, which git branch should I use?

[achow101]

Does it make sense to attempt a build on my Macbook?

If so, which git branch should I use?

Use the testing branch. Building on macs right now may not work though, but you can try.

[gangtraet]

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 
/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/Python: can't open file '/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py': [Errno 2] No such file or directory

Manually copying ArmoryQt.py into that location gives a new error:

Code:

22:29 workspace$ Armory.app/Contents/MacOS/Armory 
Traceback (most recent call last):
  File "/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py", line 37, in <module>
    from PyQt4.QtGui import *
ImportError: dlopen(/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/QtGui.so, 2): Library not loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
  Referenced from: /Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui
  Reason: Incompatible library version: QtGui requires version 46.0.0 or later, but libpng16.16.dylib provides version 45.0.0

As you can see, I have libpng installed through homebrew.  That is pretty common, though, so Armory should pick up its own version anyway.  Uninstalling libpng does not change the error, although /usr/local/opt/libpng is then gone.

[helgabutters]

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.

[Mr.Vice]

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
-INFO  - 11:05:40.531: (..\BitcoinP2P.cpp:969) Disconnected from Bitcoin node

[Mr.Vice]

Code:

-INFO  - 11:28:30.016: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:248) Listening on port 9001

Why do I have the above absolute path in my ArmoryDB log?

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.

[goatpig]

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
-INFO  - 11:05:40.531: (..\BitcoinP2P.cpp:969) Disconnected from Bitcoin node

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.

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.

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.

[Mr.Vice]

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
-INFO  - 11:05:40.531: (..\BitcoinP2P.cpp:969) Disconnected from Bitcoin node

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.

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.

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.

[alomar]

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

[goatpig]

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

[alomar]

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?

[goatpig]

987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2  armory_0.96-gcc5.4_amd64.deb
25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783  armory_0.96.0.1-testing_amd64.deb

[alomar]

987d1a262cb92a9bb70ce85ec75b15a4ef20f90c9ac322c00e7908fe086f2bf2  armory_0.96-gcc5.4_amd64.deb
25357d717452972030fa8b42017e4adf4684c354498c39002d89ee18ae551783  armory_0.96.0.1-testing_amd64.deb

thank you.

[Mr.Vice]

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

[goatpig]

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.

[goatpig]

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

[goatpig]

Need to see the log for the second build&scan

[goatpig]

This DB never got really far. Are you using an anti virus too? Your blockchain data keeps getting corrupted after the fact.

[goatpig]

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.

[Portnoy]

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

[Mr.Vice]

@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

#server=1

## Threshold for disconnecting misbehaving peers (default: 100)
banscore=80
 
## Number of seconds to keep misbehaving peers from reconnecting (default: 86400) 
bantime=1814400


## TOR & PROXY SERVER

listen=1

proxy=127.0.0.1:9050

torcontrol=127.0.0.1:9051

torpassword=***


## HIDDEN SERVICE (TOR)

#listenonion=1

## Seperate SOCKS5-Proxy for Tor Hidden Service
#onion=127.0.0.1:50959


## OTHER

#min=1

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.

[goatpig]

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

[creamers]

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

[goatpig]

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.

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.

Q: I assume my paper wallet is still usable on the new armory version?

This stuff will always be supported.

[creamers]

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)
(WARNING) SDM.pyc:395 - Spawning DB with command:./ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="D:\Bitcoin Core Database\blocks" --datadir="D:\Armory Database" --dbdir="D:\Armory Database\databases"

armorylog.txt https://pastebin.com/Q7CaghHj
dblog.txt https://pastebin.com/XVCK9Qyv

Then I saw this in eventlog on server 2008R2:

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?

[goatpig]

Is D: a USB drive?

[creamers]

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

[creamers]

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

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.

-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

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.

[Betatester]

--------------

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.

[creamers]

Restarted the 2008R2 server and running armory for the third time to see what happens.

Same problem again at the same percentage.

any suggestions ?

[Mr.Vice]

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

[Mr.Vice]

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

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.

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

[creamers]

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:

• For it's further than before with unchecked 'let armory run bitcoind in background' and server=1 and having bitcoin core running next to it: https://ibb.co/ecE1oF
• 100% and now it's Organizing chain: https://ibb.co/iA8fFv
• Now finished: https://ibb.co/d9KCvv
• BUT, after closing both bitcoin core and armory, I see the armorydb.exe still running under processes taking up 100% on one core?
• Starting armory with the armorydb.exe left behind and still running, nothing happens.
• Killed the armorydb.exe and restarted armory.
• Seems like it's going again but waiting for it to get 'online'
• ONLINE and Working
• somehow it worked to disable the bitcoind background option, but closing Armory isnt going well cause armorydb.exe stays behind...
• Balance ended into zero !  I forced rebalance after restart, but it began building databases again )-:

[goatpig]

Ima push another build tomorrow, try with that then.

[creamers]

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

2017-06-04 08:34:08 (INFO) -- qtdialogs.pyc:10895 - Wallet Restore Complete!

armorycpplog

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

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

[Mr.Vice]

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

[creamers]

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

[goatpig]

Wait, you're using a NAS? Armory doesn't work all that well with that stuff because it mmaps every file on disk.

[goatpig]

Added new builds.

[treeset]

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

[Mr.Vice]

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.

[creamers]

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.  

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.

[goatpig]

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

But, somehow armory is not seeing the whole bitcoin core chain

Did you perform a full rebuild and rescan with .0.2?

[Wiegerwijnia]

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.

[Mr.Vice]

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

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 :-)

[goatpig]

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.

[bureaucrat]

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)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries
DYLD_FRAMEWORK_PATH=/Applications/Armory.app/Contents/MacOS/../Dependencies:/Applications/Armory.app/Contents/MacOS/../Frameworks
DYLD_LIBRARY_PATH=/Applications/Armory.app/Contents/MacOS/../Dependencies:/Applications/Armory.app/Contents/MacOS/../Frameworks

Dyld Error Message:
  Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
  Referenced from: /Applications/Armory.app/Contents/MacOS/Python
  Reason: image not found

Binary Images:
       0x100000000 -        0x100000fff +Python (???) <DE9F445E-AF87-3A6F-B171-EF96DCC5B5D1> /Applications/Armory.app/Contents/MacOS/Python
       0x1016ee000 -        0x10172bdc7  dyld (433.5) <322C06B7-8878-311D-888C-C8FD2CA96FF3> /usr/lib/dyld

[gangtraet]

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

There is nothing named CppBlockUtils.* in the .app.

To me, it looks like all prerequisites are compiled and installed in the .app, but Armory itself is not.

[Mr.Vice]

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
2017-06-07 09:29:58 (INFO) -- ArmoryQt.py:4512 - Dashboard switched to auto-OfflineNoSatoshiNoInternet
2017-06-07 09:30:29 (ERROR) -- Traceback (most recent call last):
  File "qtdialogs.pyc", line 1478, in dblClickAddressView
  File "qtdialogs.pyc", line 3255, in __init__
AttributeError: 'NoneType' object has no attribute 'getLedgerDelegateForScrAddr'

[goatpig]

Ah I see. That can only happen in offline mode. Will push the fix in a few.

[droark]

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

There is nothing named CppBlockUtils.* in the .app.

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? If so, what's your setup?

[Mr.Vice]

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?

[goatpig]

You mean compressed private keys?

[gangtraet]

That means there's some sort of compile error when compiling the Armory code. Are you following the build notes? 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
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I have a good deal more installed with Homebrew than what is listed on the installation page.

Code:

~$ brew list
autoconf		jpeg			pcre
automake		lame			pkg-config
boost			libevent		povray
dcraw			libffi			python
ffmpeg			libmpc			readline
fftw			libpng			sqlite
freetype		libtiff			swig
gcc			libtool			the_silver_searcher
gdbm			libxc			ufraw
gettext			little-cms2		watch
glib			mpfr			wget
gmp			netpbm			x264
imagemagick		open-mpi		xvid
isl			openssl			xz
jasper			openssl@1.1		zlib

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

[droark]

That means there's some sort of compile error when compiling the Armory code. Are you following the build notes? 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.

[walletrecoveryservices]

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

[goatpig]

Sounds like a bug, will look into it.

[goatpig]

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.

[Carlton Banks]

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.

[gangtraet]

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:

********************************************************************************
2017-Jun-11 09:23pm
Executing: "make DESTDIR="/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py" install -j4 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Executing from: ".."
Making install in cppForSwig
Making install in lmdb
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in fcgi
make[2]: *** No rule to make target `install'.  Stop.
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
Finished executing: "make DESTDIR="/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py" install -j4 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Finished executing from: ".."
********************************************************************************

and this a bit later:

Code:

********************************************************************************
2017-Jun-11 09:23pm
Executing: "patch -p0 < /Users/****/development/BitcoinArmory/osxbuild/qmake_LFLAGS.patch 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Executing from: "/Users/****/development/BitcoinArmory/osxbuild/objc_armory"
patching file ./Makefile
Hunk #1 FAILED at 15.
1 out of 1 hunk FAILED -- saving rejects to file ./Makefile.rej
Finished executing: "patch -p0 < /Users/****/development/BitcoinArmory/osxbuild/qmake_LFLAGS.patch 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Finished executing from: "/Users/****/development/BitcoinArmory/osxbuild/objc_armory"
********************************************************************************

[droark]

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
dit submodule update

I don't know why this isn't done automatically but it seems to be required on OS X at least.

[gangtraet]

Code:

git submodule init
dit submodule update

I don't know why this isn't done automatically but it seems to be required on OS X at least.

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:

********************************************************************************
Unpacked: /Users/****/development/BitcoinArmory/osxbuild/workspace/downloads/Python-2.7.13.tar.xz
  /Users/****/development/BitcoinArmory/osxbuild/workspace/unpackandbuild/.DS_Store
  /Users/****/development/BitcoinArmory/osxbuild/workspace/unpackandbuild/Python-2.7.13
*** ERROR:  tarfile unpacked more than one object! ***
Modify Python modules setup files.
OpenSSL path = /usr/local/opt/openssl
Traceback (most recent call last):
  File "build-app.py", line 834, in <module>
    main()
  File "build-app.py", line 142, in main
    compile_python()
  File "build-app.py", line 450, in compile_python
    modSetupFile = path.join(bldPath, 'Modules/Setup.dist')
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 70, in join
    elif path == '' or path.endswith('/'):
AttributeError: 'list' object has no attribute 'endswith'

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.

[goatpig]

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.

[gangtraet]

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
# location than the location of what actually gets executed when you run Armory,
# the menu bar calls Armory "Python". However, if you symlink Python and run the
# symlink from the execution directory, the app name from Info.plist is used.
# Also, the link should be here so that the link works wherever this is
# executed, and not just on the build machine.
ln -sf "${FRDIR}/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python" "${DIRNAME}/Python"

# Assume all args are meant for Armory. Assuming otherwise, for shell scripts
# at least, it horribly painful.
exec "${DIRNAME}/Python" "${ARMORYDIR}/ArmoryQt.py" "$@"

Symptoms:

• If you download Armory as a zip file, unpack it, and run it by double-clicking Armory.app, it fails to start
• If you drag Armory to /Applications (or anywhere else for that matter), it suddenly works (since this disables App Translocation).
• Or, if you start it on the command line in the original location by typing /path/to/Armory.app/Contents/MacOS/Armory, then it is run without AppTranslocation, and works.  Now the softlink has been made, and double-clicking on Armory.app will now work (since although App Translocation is still in place, the softlink was made in the original App)

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.

[gangtraet]

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
2017-06-12 20:59:38 (INFO) -- ArmoryUtils.py:3587 - Using settings file: /Users/****/Library/Application Support/Armory/ArmorySettings.txt
2017-06-12 20:59:38 (ERROR) -- ArmoryUtils.py:3744 - Unsupported language  specified. Defaulting to English (en)
2017-06-12 20:59:38 (INFO) -- ArmoryUtils.py:3747 - Using Language: en
2017-06-12 20:59:38 (INFO) -- BDM.py:365 - Using the asynchronous/multi-threaded BlockDataManager.
2017-06-12 20:59:38 (INFO) -- BDM.py:366 - Blockchain operations will happen in the background.  
2017-06-12 20:59:38 (INFO) -- BDM.py:367 - Devs: check TheBDM.getState() before asking for data.
2017-06-12 20:59:38 (INFO) -- BDM.py:368 - Registering addresses during rescans will queue them for 
2017-06-12 20:59:38 (INFO) -- BDM.py:369 - inclusion after the current scan is completed.
2017-06-12 20:59:38 (ERROR) -- ArmoryQt.py:5892 - Socket already in use.  Sent CLI args to existing proc.
2017-06-12 20:59:38 (ERROR) -- ArmoryQt.py:5893 - Exiting...

[goatpig]

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

[creamers]

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.

[goatpig]

Post armorylog.txt

[creamers]

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

I think this is some sort of gui bug thingy ? :   http://imgur.com/a/ECgRQ

[goatpig]

Bumping for the new testing builds.

[creamers]

Nice! ( https://github.com/goatpig/BitcoinArmory/commit/eb826b671155eb57fe7271c8d140431ebe8b8bbc )
Will test some more.

*EDIT

First time after installation after every startup and changing the comments it flipped back. The second edit it didnt flip back to my wallet and stayed at all wallets.

[goatpig]

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.

[creamers]

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)

[creamers]

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
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1252 - 
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1253 - 
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1254 - 
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1255 - ************************************************************
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1256 - Invoked: C:\Program Files (x86)\Armory\ArmoryQt.exe --datadir=c:\Armory Database --satoshi-datadir=c:\Bitcoin Core Database
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1257 - ************************************************************
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1258 - Loading Armory Engine:
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1259 -    Armory Version        : 0.96.0.3
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1260 -    Armory Build:         : 1a126dd6ec
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1261 -    PyBtcWallet  Version  : 1.35
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1262 - Detected Operating system: Windows
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1263 -    OS Variant            : 2008ServerR2-6.1.7601-SP1-Multiprocessor Free
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1264 -    User home-directory   : C:\Users\Administrator\AppData\Roaming
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1265 -    Satoshi BTC directory : c:\Bitcoin Core Database
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1266 -    Armory home dir       : c:\Armory Database
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1267 - Detected System Specs    : 
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1268 -    Total Available RAM   : 3.87 GB
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1269 -    CPU ID string         : AMD64 Family 16 Model 6 Stepping 3, AuthenticAMD
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1270 -    Number of CPU cores   : 2 cores
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1271 -    System is 64-bit      : True
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1272 -    Preferred Encoding    : cp1252
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1273 -    Machine Arch          : amd64
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1274 -    Available HDD (ARM)   : 657 GB
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1275 -    Available HDD (BTC)   : 657 GB
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1276 - 
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1277 - Network Name: Main Network
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1278 - Satoshi Port: 8333
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1279 - Do wlt check: True
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1280 - Named options/arguments to armoryengine.py:
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     thread_count    : -1
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     rescan          : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     ignoreAllZC     : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     rescanBalance   : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     disableModules  : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     port            : None
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     interport       : 8223
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     coverageOutputDir: None
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     forceWalletCheck: False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     regtest         : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     rebuild         : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     nettimeout      : 2
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     datadir         : c:\Armory Database
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     clearMempool    : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     offline         : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     armoryDBDir     : DEFAULT
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     armorydb_port   : 9001
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     satoshiPort     : DEFAULT
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     useTorSettings  : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     netlog          : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     keypool         : 100
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     coverageInclude : None
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     forceOnline     : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     redownload      : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     rpcBindAddr     : 127.0.0.1
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     armorydb_ip     : 127.0.0.1
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     multisigFile    : DEFAULT
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     ram_usage       : -1
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     mtdebug         : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     logDisable      : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     settingsPath    : c:\Armory Database\ArmorySettings.txt
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     language        : en
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     db_type         : DB_FULL
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     doDebug         : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     enableDetSign   : True
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     disableConfPermis: False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     testnet         : False
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     rpcport         : DEFAULT
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     satoshiHome     : c:\Bitcoin Core Database
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     satoshiRpcport  : DEFAULT
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     logFile         : c:\Armory Database\ArmoryQt.exe.log.txt
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1282 -     verbosity       : None
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1283 - Other arguments:
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1286 - ************************************************************
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:1689 - C++ block utilities loaded successfully
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:3587 - Using settings file: c:\Armory Database\ArmorySettings.txt
2017-06-14 19:53:13 (ERROR) -- ArmoryUtils.pyc:3744 - Unsupported language  specified. Defaulting to English (en)
2017-06-14 19:53:13 (INFO) -- ArmoryUtils.pyc:3747 - Using Language: en
2017-06-14 19:53:13 (INFO) -- BDM.pyc:365 - Using the asynchronous/multi-threaded BlockDataManager.
2017-06-14 19:53:13 (INFO) -- BDM.pyc:366 - Blockchain operations will happen in the background.  
2017-06-14 19:53:13 (INFO) -- BDM.pyc:367 - Devs: check TheBDM.getState() before asking for data.
2017-06-14 19:53:13 (INFO) -- BDM.pyc:368 - Registering addresses during rescans will queue them for 
2017-06-14 19:53:13 (INFO) -- BDM.pyc:369 - inclusion after the current scan is completed.
2017-06-14 19:53:14 (INFO) -- ArmoryUtils.pyc:3587 - Using settings file: c:\Armory Database\ArmorySettings.txt
2017-06-14 19:53:14 (INFO) -- ArmoryQt.py:2045 - loadWalletsAndSettings
2017-06-14 19:53:14 (INFO) -- ArmoryQt.py:2105 - Loading wallets...
2017-06-14 19:53:16 (INFO) -- ArmoryQt.py:2170 - Number of wallets read in: 2
2017-06-14 19:53:16 (INFO) -- ArmoryQt.py:2175 -    Wallet (7GuJwatF):    "BurtsWallet (Watch)             "   (No Encryption)
2017-06-14 19:53:16 (INFO) -- ArmoryQt.py:2175 -    Wallet (DW1EHSXZ):    "Restored - DW1EHSXZ             "   (Encrypted)
2017-06-14 19:53:16 (INFO) -- ArmoryQt.py:1747 - acquiring process mutex...
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1386 - setupUriRegistration
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1454 - Armory already registered for current user.  Done!
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:560 - Usermode: Advanced
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1682 - Changing usermode:
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1683 -    From: Advanced
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1691 -      To: Advanced
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1820 - startBitcoindIfNecessary
2017-06-14 19:53:17 (INFO) -- ArmoryQt.py:1856 - setSatoshiPaths
2017-06-14 19:53:17 (INFO) -- SDM.pyc:251 - Found Bitcoin Core link on desktop: C:\Program Files\Bitcoin
2017-06-14 19:53:17 (INFO) -- SDM.pyc:251 - Found Bitcoin Core link on desktop: C:\Program Files\Bitcoin
2017-06-14 19:53:17 (INFO) -- SDM.pyc:169 - Found bitcoind in the following places:
2017-06-14 19:53:17 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-06-14 19:53:17 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-06-14 19:53:17 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-06-14 19:53:17 (INFO) -- SDM.pyc:173 - Using: C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-06-14 19:53:17 (INFO) -- SDM.pyc:337 - Called startBitcoind
2017-06-14 19:53:18 (INFO) -- ArmoryUtils.pyc:664 - Executing popen: ['C:\\Program Files\\Bitcoin\\daemon\\bitcoind.exe', u'-datadir=c:\\Bitcoin Core Database']
2017-06-14 19:53:18 (INFO) -- SDM.pyc:442 - PID of bitcoind: 17984
2017-06-14 19:53:18 (INFO) -- SDM.pyc:443 - PID of armory:   4924
2017-06-14 19:53:18 (INFO) -- ArmoryUtils.pyc:664 - Executing popen: ['.\\guardian.exe', '4924', '17984']
2017-06-14 19:53:21 (INFO) -- ArmoryQt.py:1856 - setSatoshiPaths
2017-06-14 19:53:21 (WARNING) -- SDM.pyc:395 - Spawning DB with command:./ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="c:\Bitcoin Core Database\blocks" --datadir="c:\Armory Database" --dbdir="c:\Armory Database\databases"
2017-06-14 19:53:21 (INFO) -- ArmoryUtils.pyc:664 - Executing popen: ['./ArmoryDB.exe', '--db-type="DB_FULL"', '--cookie', u'--satoshi-datadir="c:\\Bitcoin Core Database\\blocks"', '--datadir="c:\\Armory Database"', u'--dbdir="c:\\Armory Database\\databases"']
2017-06-14 19:53:23 (INFO) -- ArmoryQt.py:1808 - Connecting on port 50655
2017-06-14 19:53:23 (INFO) -- ArmoryQt.py:1908 - Setting netmode: 1
2017-06-14 19:53:24 (INFO) -- ArmoryQt.py:1890 - loadBlockchainIfNecessary
2017-06-14 19:53:25 (INFO) -- ArmoryQt.py:1908 - Setting netmode: 1
2017-06-14 19:53:25 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:25 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:25 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:25 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:26 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:27 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:28 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:29 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:30 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:31 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:32 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:33 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:45 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:48 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:48 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:49 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:53:49 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-06-14 19:54:15 (WARNING) -- ArmoryQt.py:4078 - Called updateSyncProgress while not sync'ing
2017-06-14 20:00:38 (INFO) -- ArmoryQt.py:4914 - New Block! : 471263
2017-06-14 20:00:38 (INFO) -- ArmoryQt.py:4922 - Current block number: 471263
2017-06-14 20:13:33 (INFO) -- ArmoryQt.py:4914 - New Block! : 471264
2017-06-14 20:13:33 (INFO) -- ArmoryQt.py:4922 - Current block number: 471264
2017-06-14 20:19:23 (INFO) -- ArmoryQt.py:4914 - New Block! : 471265
2017-06-14 20:19:23 (INFO) -- ArmoryQt.py:4922 - Current block number: 471265
2017-06-14 20:23:18 (WARNING) -- ArmoryQt.py:4078 - Called updateSyncProgress while not sync'ing

Code:

-WARN  - 20:22:40.241: (..\BDM_supportClasses.cpp:1898) running 2285 zc parser threads
-WARN  - 20:22:40.241: (..\BDM_supportClasses.cpp:1898) running 2290 zc parser threads
-WARN  - 20:22:53.924: (..\BDM_supportClasses.cpp:1898) running 2295 zc parser threads
-WARN  - 20:22:53.924: (..\BDM_supportClasses.cpp:1898) running 2300 zc parser threads
-WARN  - 20:22:53.939: (..\BDM_supportClasses.cpp:1898) running 2305 zc parser threads
-WARN  - 20:22:53.939: (..\BDM_supportClasses.cpp:1898) running 2310 zc parser threads
-WARN  - 20:22:53.955: (..\BDM_supportClasses.cpp:1898) running 2315 zc parser threads
-ERROR - 20:23:18.024: (..\SocketObject.cpp:285--ERROR - 20:23:18.040: (WARN  - ..\SocketObject.cpp:134) POLLERR error in readFromSocketThread
20:23:18.040) POLLERR in writeToSocket
: (..\BDM_supportClasses.cpp:1898) running 2320 zc parser threads
-WARN  - 20:23:18.055: (..\BDM_supportClasses.cpp:1898) running 2325 zc parser threads
-WARN  - 20:23:18.071: (..\BDM_supportClasses.cpp:1898) running 2330 zc parser threads
-WARN  - 20:23:18.071: (..\BDM_supportClasses.cpp:1898) running 2335 zc parser threads
-ERROR - 20:23:18.087: (..\SocketObject.cpp:134) POLLERR in writeToSocket
-ERROR - 20:23:18.087: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038
-ERROR - 20:23:18.102: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038
-WARN  - 20:23:18.102: (..\BDM_supportClasses.cpp:1898) running 2340 zc parser threads
-ERROR - 20:23:18.133: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038
-ERROR - 20:23:18.133: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038
-WARN  - 20:23:18.149: (..\BDM_supportClasses.cpp-ERROR - :189820:23:18.149: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038) running 2345
 zc parser threads-ERROR - 
20:23:18.165: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038
-ERROR - 20:23:18.180: (..\SocketObject.cpp:126-WARN  - ) 20:23:18.196: (..\BDM_supportClasses.cpp:1898poll() error in writeToSocket: 10038
) running 2350 zc parser threads
-ERROR - 20:23:18.196: (..\SocketObject.cpp:126) poll() error in writeToSocket: 10038
-ERROR - 20:23:18.211: (..\SocketObject.cpp:126-ERROR - ) 20:23:18.211: (..\BitcoinP2P.cpp:1027poll() error in writeToSocket: 10038) caught SocketError exception in processDataStackThread: POLLERR error in readFromSocketThread

-ERROR - -INFO  - 20:23:18.227: (..\SocketObject.cpp:12620:23:18.227: (..\BitcoinP2P.cpp:969) ) Disconnected from Bitcoin node
poll() error in writeToSocket: 10038

[goatpig]

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?

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

[idoB]

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
still there in 96.1.0.3 (same error in log).

Log:

Code:

 (ERROR) -- Traceback (most recent call last):
  File "ui\WalletFrames.pyc", line 1136, in clickedDoIt
  File "qtdialogs.pyc", line 4947, in __init__
  File "qtdialogs.pyc", line 5006, in rewriteList
  File "CppBlockUtils.pyc", line 4035, in getAddrObjByIndex
RuntimeError: invalid asset index

[creamers]

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

dblog:
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.)

[creamers]

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

[goatpig]

Pushed a fix for that

[creamers]

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.

[Mr.Vice]

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
Traceback (most recent call last):
  File "qtdialogs.pyc", line 5834, in showTxOutDialog
  File "qtdialogs.pyc", line 6074, in __init__
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 51: ordinal not in range(128)
2017-06-19 16:16:55 (ERROR) -- Traceback (most recent call last):
  File "ui\TxFrames.pyc", line 2091, in loadTx
UnicodeEncodeError: 'ascii' codec can't encode character u'\xd6' in position 16: ordinal not in range(128)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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):
  File "qtdialogs.pyc", line 8086, in acceptAddrSelection
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 4: ordinal not in range(128)

2017-06-19 16:36:42 (ERROR) -- Traceback (most recent call last):
  File "qtdialogs.pyc", line 7995, in dblClickAddressRx
  File "qtdialogs.pyc", line 8086, in acceptAddrSelection
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 4: ordinal not in range(128)

2017-06-19 16:36:47 (ERROR) -- Traceback (most recent call last):
  File "qtdialogs.pyc", line 8086, in acceptAddrSelection
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 4: ordinal not in range(128)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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&#2).
*** PROBABLY SOLVED: INSUFFICIENT FUNDING (MAX. INPUT SPENDING) ***

armorylog.txt

Code:

2017-06-19 19:24:43 (ERROR) -- Traceback (most recent call last):
  File "ArmoryQt.py", line 3379, in showContextMenuLedger
  File "ArmoryQt.py", line 5920, in bumpFee
  File "ui\TxFrames.pyc", line 1296, in prefillFromBatch
  File "ui\TxFrames.pyc", line 1335, in prefill
  File "ui\TxFrames.pyc", line 335, in addOneRecipient
  File "ui\TxFrames.pyc", line 500, in resolveCoinSelection
RuntimeError: Invalid spend value

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Kind regards :-)

[Tmptmpbuggyguy]

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.

[goatpig]

Will there be offline bundles for the next release?

Yes

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.

[Tmptmpbuggyguy]

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.

[goatpig]

Ask droark, he takes care of the OSX stuff.

[Tmptmpbuggyguy]

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

[goatpig]

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.

[Tmptmpbuggyguy]

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'

but same problem.

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
git submodule update

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.
make[2]: *** [ArmoryDB-BtcWallet.o] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
Finished executing: "make DESTDIR="/Users/username/Documents/Code/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py" install -j4 2>&1 | tee -a /Users/username/Documents/Code/BitcoinArmory/osxbuild/build-app.log.txt"
Finished executing from: ".."

............

2017-Jun-26 09:41pm
Executing: "patch -p0 < /Users/username/Documents/Code/BitcoinArmory/osxbuild/qmake_LFLAGS.patch 2>&1 | tee -a /Users/username/Documents/Code/BitcoinArmory/osxbuild/build-app.log.txt"
Executing from: "/Users/username/Documents/Code/BitcoinArmory/osxbuild/objc_armory"
patching file ./Makefile
Hunk #1 FAILED at 15.
1 out of 1 hunk FAILED -- saving rejects to file ./Makefile.rej
Finished executing: "patch -p0 < /Users/username/Documents/Code/BitcoinArmory/osxbuild/qmake_LFLAGS.patch 2>&1 | tee -a /Users/username/Documents/Code/BitcoinArmory/osxbuild/build-app.log.txt"
Finished executing from: "/Users/username/Documents/Code/BitcoinArmory/osxbuild/objc_armory"
********************************************************************************

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
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _CppBlockUtils.so             	0x0000000104dc1d22 void CryptoPP::GetUserKey<unsigned int>(CryptoPP::ByteOrder, unsigned int*, unsigned long, unsigned char const*, unsigned long) + 450
1   _CppBlockUtils.so             	0x0000000104e359a5 CryptoPP::Rijndael::Base::UncheckedSetKey(unsigned char const*, unsigned int, CryptoPP::NameValuePairs const&) + 197
2   _CppBlockUtils.so             	0x0000000104deab64 CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(unsigned char const*, unsigned long, unsigned char const*, unsigned char const*) + 196
3   _CppBlockUtils.so             	0x0000000104dea962 CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(bool, unsigned char const*, unsigned long) + 450
4   _CppBlockUtils.so             	0x0000000104b86dc0 SecureBinaryData::GenerateRandom(unsigned int, SecureBinaryData) + 80
5   _CppBlockUtils.so             	0x0000000104bc50f9 BlockDataManagerConfig::BlockDataManagerConfig() + 457
6   _CppBlockUtils.so             	0x0000000104d21634 _wrap_new_BlockDataManagerConfig(_object*, _object*) + 68

[gangtraet]

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

[Tmptmpbuggyguy]

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)

[gangtraet]

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.

[Tmptmpbuggyguy]

Code:

MacBook-Pro:Desktop myusername$ Armory.app/Contents/MacOS/Armory
/Users/myusername
Illegal instruction: 4

Then Mac OS crash report opens. I pm'ed you the full report.

[gangtraet]

Ouch!  I cannot really read the crash report, but I notice this part:

Code:

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)

Termination Signal:    Illegal instruction: 4

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.

[Tmptmpbuggyguy]

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)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _CppBlockUtils.so             	0x0000000104d82222 void CryptoPP::GetUserKey<unsigned int>(CryptoPP::ByteOrder, unsigned int*, unsigned long, unsigned char const*, unsigned long) + 450
1   _CppBlockUtils.so             	0x0000000104df5ea5 CryptoPP::Rijndael::Base::UncheckedSetKey(unsigned char const*, unsigned int, CryptoPP::NameValuePairs const&) + 197
2   _CppBlockUtils.so             	0x0000000104dab064 CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(unsigned char const*, unsigned long, unsigned char const*, unsigned char const*) + 196
3   _CppBlockUtils.so             	0x0000000104daae62 CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(bool, unsigned char const*, unsigned long) + 450
4   _CppBlockUtils.so             	0x0000000104b45e80 SecureBinaryData::GenerateRandom(unsigned int, SecureBinaryData) + 80
5   _CppBlockUtils.so             	0x0000000104b85349 BlockDataManagerConfig::BlockDataManagerConfig() + 457
.....

Code:

Binary Images:
       0x100000000 -        0x100000fff +Python (???) <DE9F445E-AF87-3A6F-B171-EF96DCC5B5D1> /Users/USER/Desktop/Armory.app/Contents/MacOS/Python
       0x100003000 -        0x100044ff7 +libssl.1.0.0.dylib (0) <35C152E0-7168-3B99-94AB-ECA04D3B3DB5> /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
       0x100062000 -        0x1001d2727 +libcrypto.1.0.0.dylib (0) <11B495A9-782C-3FB0-9729-ACFCD9F4F53E> /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
       0x10024b000 -        0x1003a8ff7 +org.python.python (2.7.13, [c] 2001-2016 Python Software Foundation. - 2.7.13) <D1108E8D-C9FE-3E53-B9E4-D5F34B9BD38F> /Users/USER/Desktop/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/Python
       0x1004f9000 -        0x1004fbfff +_locale.so (???) <05973DD6-F503-354D-BE3C-2996D8477180> /Users/USER/Desktop/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
       0x101a40000 -        0x101a48ff3 +libintl.8.dylib (0) <9A1967E0-AC59-3EF6-B14F-643AF08A6B4F> /usr/local/opt/gettext/lib/libintl.8.dylib
       0x101b4d000 -        0x101b51ff7 +operator.so (???) <ECA4F01C-D5B9-3160-B75B-76044F66A3EF> /Users/USER/Desktop/

.....

Maybe it's related to this issue: https://stackoverflow.com/questions/38167803/genymotion-crash-on-start-in-osx

[gangtraet]

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
cd BitcoinArmory
git submodule init
git submodule update

then you should have the complete source code.


EDIT: spelling.

[Tmptmpbuggyguy]

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
cd BitcoinArmory
git submodule init
git submodule update

then you should have the complete source code.

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
dit submodule update

(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):
  File "/Users/user/Desktop/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py", line 37, in <module>
    from PyQt4.QtGui import *
ImportError: dlopen(/Users/user/Desktop/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/QtGui.so, 2): Library not loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
  Referenced from: /Users/user/Desktop/Armory.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui
  Reason: Incompatible library version: QtGui requires version 46.0.0 or later, but libpng16.16.dylib provides version 45.0.0

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.
 

[naska21]

@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

[goatpig]

Thanks for the report, will look into it.

[Casimir1904]

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'

[goatpig]

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?

[goatpig]

@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?

[naska21]

@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

[goatpig]

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

[Casimir1904]

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):
  File "/usr/local/bin/../lib/armory/ArmoryQt.py", line 648, in <lambda>
    execAbout   = lambda: DlgHelpAbout(self).exec_()
  File "/usr/local/lib/armory/qtdialogs.py", line 8241, in __init__
    lblHead = QRichLabel(self.tr('Armory Bitcoin Wallet : Version %1-beta-%2').arg(getVersionString(BTCARMORY_VERSION), BTCARMORY_BUILD), doWrap=False)
TypeError: arguments did not match any overloaded call:
  arg(self, int, fieldWidth: int = 0, base: int = 10, fillChar: QChar = QLatin1Char(' ')): argument 1 has unexpected type 'str'
  arg(self, float, fieldWidth: int = 0, format: str = 'g', precision: int = -1, fillChar: QChar = QLatin1Char(' ')): argument 1 has unexpected type 'str'
  arg(self, int, fieldWidth: int = 0, base: int = 10, fillChar: QChar = QLatin1Char(' ')): argument 1 has unexpected type 'str'
  arg(self, int, fieldWidth: int = 0, base: int = 10, fillChar: QChar = QLatin1Char(' ')): argument 1 has unexpected type 'str'
  arg(self, QString, fieldWidth: int = 0, fillChar: QChar = QLatin1Char(' ')): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'
  arg(self, QString, QString, QString, QString, QString, QString, QString, QString, QString): argument 2 has unexpected type 'NoneType'

Edit:
building from your newest pushes gives:
./configure: line 18156: syntax error near unexpected token `fi'

Code:

else
  as_fn_error $? "missing swig!" "$LINENO" 5
fi
fi

Fixed that one manual but you might want to check it :-)

[goatpig]

Both fixed now.

[naska21]

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?

[goatpig]

Fix is in the repo, no builds for it yet.

[Casimir1904]

Both fixed now.

Will pull later and report if i find other issues.

[Stroto]

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
2017-07-04 09:11:50 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-07-04 09:11:50 (INFO) -- ArmoryQt.py:4640 - Dashboard switched to "Scanning" mode
2017-07-04 09:33:12 (INFO) -- ArmoryQt.py:4914 - New Block! : 474153
2017-07-04 09:33:12 (INFO) -- ArmoryQt.py:4922 - Current block number: 474153
2017-07-04 09:40:09 (INFO) -- ArmoryQt.py:5333 - Bitcoins Sent!
Amount:  X BTC
From:    X
To:      X
2017-07-04 09:43:20 (INFO) -- ArmoryQt.py:4914 - New Block! : 474154
2017-07-04 09:43:20 (INFO) -- ArmoryQt.py:4922 - Current block number: 474154

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?

[goatpig]

Is the fee bigger than what you are sending?

[Stroto]

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.

[goatpig]

Testing builds #4 are out.

[goatpig]

Try the latest builds.

[idoB]

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)

Thanks for that, goatpig!

[wachtwoord]

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

[goatpig]

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.

[naska21]

@goatpig, Hi, just downloaded sha256sum.txt.asc but  it seems that it cointains only  SHA256 hash for Debian version of Armory but not for armory_0.96.0.4-testing_win64  Please, renew sha256sum   so that I could check win64 file  Thanks in advance

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

[paranoidx]

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

[paranoidx]

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

[paranoidx]

Okay it seems core wasnt running correctly in the background that 2nd time.  All good now. I was able to send transaction.

[creamers]

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!

[naska21]

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?

[Tmptmpbuggyguy]

Armory 0.96.0.3 is stuck and says "Building databases ... 15 Minutes".

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

-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

(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

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

[Tmptmpbuggyguy]

I'm still not able to get a working build of the OS X version > Armory 0.96.0.

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.

[XCTfluid]

Is there change log for test builds? Just can't find it now. Anyway not big deal, just curious.

[goatpig]

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.

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.

[Tmptmpbuggyguy]

OK thanks goatpig. Meanwhile I try to get my 0.96 working again.

-DEBUG - 1499774917: (Blockchain.cpp:242) Organizing chain
-INFO  - 1499775031: (DatabaseBuilder.cpp:56) updated HEADERS db in 6514s
-INFO  - 1499775032: (BlockUtils.cpp:1206) Enabling zero-conf tracking

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?

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

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 !?!?

[goatpig]

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.

[gangtraet]

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.

[goatpig]

You do not build on RPi. You cross compiled from a Linux machine:

https://github.com/goatpig/BitcoinArmory/blob/master/r-pi/README.md

[gangtraet]

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

[gangtraet]

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.

[creamers]

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

[goatpig]

I don't have Flash installed so I can't watch this video.

[creamers]

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

[goatpig]

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.

[Mr.Vice]

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):
  File "qtdialogs.pyc", line 8091, in acceptAddrSelection
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 4: ordinal not in range(128)

------------------------------------------------------------------------------------------------------------------------------------------------
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...
-INFO  - 09:21:45.219: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:249) Listening on port 52144
-INFO  - 09:21:45.344: (..\BlockUtils.cpp:1092) Executing: doInitialSyncOnLoad
-INFO  - 09:21:45.391: (..\DatabaseBuilder.cpp:190) Reading headers from db
-INFO  - 09:21:48.203: (..\BDM_Server.cpp:1074) registered bdv: 87a75e5d94283b58e55b
-WARN  - 09:23:13.500: (..\Blockchain.cpp:63) block id duplicate: 476093
-INFO  - 09:24:19.188: (..\DatabaseBuilder.cpp:229) Found 475996 headers in db
-INFO  - 09:24:21.438: (..\DatabaseBuilder.cpp:63) Rewinding 100 blocks
-INFO  - 09:24:21.438: (..\DatabaseBuilder.cpp:70) updating HEADERS db
-INFO  - 09:24:28.766: (..\DatabaseBuilder.cpp:272) parsed block file #937
-INFO  - 09:24:29.610: (..\DatabaseBuilder.cpp:272) parsed block file #938
-INFO  - 09:24:30.610: (..\DatabaseBuilder.cpp:482) Found next block after skipping 998205bytes
-INFO  - 09:24:31.500: (..\DatabaseBuilder.cpp:272) parsed block file #939
-INFO  - 09:24:31.500: (..\Blockchain.cpp:246) Organizing chain 
-INFO  - 09:24:31.563: (..\Blockchain.cpp:360) Organized chain in 0.062s
-INFO  - 09:24:31.719: (..\DatabaseBuilder.cpp:75) updated HEADERS db in 10.283s
-INFO  - 09:24:31.719: (..\DatabaseBuilder.cpp:1121) verifying txfilters integrity
-INFO  - 09:26:09.266: (..\DatabaseBuilder.cpp:1205) done checking txfilters
-INFO  - 09:26:09.875: (..\DatabaseBuilder.cpp:127) scanning new blocks from #475996 to #476432
-INFO  - 09:26:11.578: (..\BlockchainScanner.cpp:665) scanned from height #475996 to #476432
-INFO  - 09:26:11.703: (..\BlockchainScanner.cpp:225) scanned transaction history in 1.813s
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:313) gc count: 5
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:314) peak: 5
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:316)    file id: 935
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:316)    file id: 936
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:316)    file id: 937
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:316)    file id: 938
-INFO  - 09:26:11.703: (..\BlockDataMap.cpp:316)    file id: 939
-INFO  - 09:26:11.953: (..\DatabaseBuilder.cpp:177) scanned new blocks in 2.083s
-INFO  - 09:26:11.953: (..\DatabaseBuilder.cpp:181) init db in 266.61s
-INFO  - 09:26:11.953: (..\BDM_supportClasses.cpp:1873) Enabling zero-conf tracking
-ERROR - 09:28:12.578: (..\SocketObject.cpp:290) POLLERR error in readFromSocketThread
-ERROR - 09:28:12.672: (..\BitcoinP2P.cpp:1027) caught SocketError exception in processDataStackThread: POLLERR error in readFromSocketThread

dbLog.txt (No.2)

Code:

-INFO  - 09:45:43.125: (..\lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 09:45:44.484: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:249) Listening on port 56843
-INFO  - 09:45:44.906: (..\BlockUtils.cpp:1092) Executing: doInitialSyncOnLoad
-INFO  - 09:45:44.015: (..\DatabaseBuilder.cpp:190) Reading headers from db
-INFO  - 09:45:45.953: (..\BDM_Server.cpp:1074) registered bdv: 98376ae835966ed6a09e
-WARN  - 09:46:43.343: (..\Blockchain.cpp:63) block id duplicate: 476093
-INFO  - 09:47:18.406: (..\DatabaseBuilder.cpp:229) Found 476433 headers in db
-INFO  - 09:47:20.515: (..\DatabaseBuilder.cpp:63) Rewinding 100 blocks
-INFO  - 09:47:20.515: (..\DatabaseBuilder.cpp:70) updating HEADERS db
-INFO  - 09:47:22.484: (..\DatabaseBuilder.cpp:482) Found next block after skipping 997872bytes
-INFO  - 09:47:22.546: (..\DatabaseBuilder.cpp:272) parsed block file #939
-INFO  - 09:47:23.750: (..\Blockchain.cpp:246) Organizing chain 
-INFO  - 09:47:23.796: (..\Blockchain.cpp:360) Organized chain in 0.047s
-INFO  - 09:47:23.812: (..\DatabaseBuilder.cpp:75) updated HEADERS db in 3.297s
-INFO  - 09:47:23.812: (..\DatabaseBuilder.cpp:1121) verifying txfilters integrity
-INFO  - 09:47:58.750: (..\DatabaseBuilder.cpp:1205) done checking txfilters
-INFO  - 09:47:58.078: (..\DatabaseBuilder.cpp:127) scanning new blocks from #476433 to #476441
-INFO  - 09:47:59.500: (..\BlockchainScanner.cpp:665) scanned from height #476433 to #476441
-INFO  - 09:47:59.500: (..\BlockDataMap.cpp:313) gc count: 1
-INFO  - 09:47:59.500: (..\BlockDataMap.cpp:314) peak: 1
-INFO  - 09:47:59.500: (..\BlockDataMap.cpp:316)    file id: 939
-INFO  - 09:47:59.562: (..\DatabaseBuilder.cpp:177) scanned new blocks in 0.485s
-INFO  - 09:47:59.562: (..\DatabaseBuilder.cpp:181) init db in 134.655s
-INFO  - 09:47:59.562: (..\BDM_supportClasses.cpp:1873) Enabling zero-conf tracking
-INFO  - 09:51:18.796: (..\BitcoinP2P.cpp:947) Connected to Bitcoin node
-INFO  - 09:55:10.062: (..\DatabaseBuilder.cpp:482) Found next block after skipping 17845bytes
-INFO  - 09:58:33.625: (..\BlockchainScanner.cpp:665) scanned from height #476442 to #476442
-WARN  - 10:02:26.515: (..\BDM_supportClasses.cpp:1937) running 10 zc parser threads
-INFO  - 10:02:27.765: (..\BlockchainScanner.cpp:665) scanned from height #476443 to #476443
-INFO  - 10:04:52.937: (..\BlockchainScanner.cpp:665) scanned from height #476444 to #476446
-INFO  - 10:05:58.796: (..\BlockchainScanner.cpp:665) scanned from height #476447 to #476447
-INFO  - 10:07:01.515: (..\BlockchainScanner.cpp:665) scanned from height #476448 to #476448
-INFO  - 10:07:41.765: (..\BlockchainScanner.cpp:665) scanned from height #476449 to #476449
-INFO  - 10:08:36.890: (..\BlockchainScanner.cpp:665) scanned from height #476450 to #476450
-INFO  - 10:09:10.609: (..\BlockchainScanner.cpp:665) scanned from height #476451 to #476451
-INFO  - 10:10:00.812: (..\BlockchainScanner.cpp:665) scanned from height #476452 to #476452
-WARN  - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 15 zc parser threads
-WARN  - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 20 zc parser threads
-WARN  - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 25 zc parser threads
-WARN  - 10:10:52.421: (..\BDM_supportClasses.cpp:1937) running 30 zc parser threads
-ERROR - 10:10:53.734: (..\BlockchainScanner.cpp:271) raw data does not match expected block hash

------------------------------------------------------------------------------------------------------------------------------------------------

[goatpig]

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.

[Mr.Vice]

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 :-)

[goatpig]

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.

[gangtraet]

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.

[goatpig]

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.

[Mr.Vice]

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?

[goatpig]

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.

[alomar]

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.

[goatpig]

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.

[WiiD]

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

[goatpig]

logs

[WiiD]

Where do I find them?

[goatpig]

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockDataManagerConfig.cpp#L32

[WiiD]

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

[goatpig]

Code:

const string BlockDataManagerConfig::defaultDataDir_ = 
   "~/Armory";

This is where you find your logs. Otherwise extract them from the file menu option.

[WiiD]

http://pastebin.ca/3848861

[WiiD]

http://pastebin.ca/3848861

Please help me, I need to access my BTCs, it is all my money.

[goatpig]

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.

[Holliday]

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