Title: Armory 0.95 testing phase
Post by: goatpig on July 25, 2016, 01:19:42 AM
It's that time again. Calling on testers to build the dev branch for the time being. You can see the current change set here:
https://github.com/goatpig/BitcoinArmory/blob/dev/changelog.txt
This covers the core of the update, i.e. litenode. Some GUI stuff is broken, mainly the address book, the wallet filter drop down list, progress bars and the some data in the wallet properties dialog.
Also unit tests are out whack and there a few pull requests I'm going over at the moment, notably one for SegWit scanning support submitted by achow101 (many thanks =D).
There are still a few convenience features I haven't implemented yet, albeit they should be done quickly, notably:
- a change to guardian to prevent ungraceful bitcoind shutdowns. This should fix a lot of corruption issues.
- a dust-be-gone feature for coin control.
- a fee per byte feature in spend dialogs with tx size projections.
Once the current the outstanding issues (and anything you guys find in the process) are fixed, we'll move to testing binaries.
Stuff that won't be in the scope of this release and when to expect them:
- New wallets: That's for 0.96, with full SegWit support (create and spend from SW transactions).
- HW wallets support: Most likely a point release for 0.96.
- Fee estimates: Expect a point release on top of 0.95 (.1~2)
- Blocks over P2P. 0.97 most likely
- DB to Client encryption and auth. Again, probably 0.97
- Code modularization: most of it for 0.96
- Supernode: 0.98
This is rather massive change to the code base with big overhauls under the hood. Expect a decent amount of bugs. It will make implementing and testing the new features a lot faster and safer as a return.
Happy testing =)
P.S. I'll be away on the 25-26th. Will go over bug reports starting Wednesday
Title: Re: Armory 0.95 testing phase
Post by: Iconiplex on July 25, 2016, 07:02:20 AM
Just to clarify some changes in the first step of this P2P process as I think the litenode is something a ton of people will be thrilled about: since ArmoryQt relies on ArmoryDB, I imagine this means remote connections are only compatible with nodes running ArmoryDB and so end-users will need to wait until people begin hosting reliable Armory nodes? In other words, remote connections to nodes exclusively running Bitcoin Classic/Core/etc. are not supported, though this issue will be later mitigated by P2P node support in ArmoryDB (essentially allowing a user to run ArmoryDB locally but pull from a Classic node) and/or implementation of the supernode?
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 25, 2016, 10:18:14 AM
I shall be firing up my compiler a little later.
Good to get an outline on the development schedule too, although I'm aware of how/why sometimes things can slip.
Re: 0.93.3 users, any plans to get a website yet?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 25, 2016, 02:55:18 PM
Anyone else getting this error: /home/andy/bitcoin/BitcoinArmory/armoryengine/Transaction.py:2657: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 6678, in method_signal
method()
File "ArmoryQt.py", line 6718, in completeBlockchainProcessingInitialization
self.setupLedgerViews()
File "ArmoryQt.py", line 6733, in setupLedgerViews
self.ledgerModel.setLedgerDelegate(TheBDM.bdv().getLedgerDelegateForWallets())
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1247, in getLedgerDelegateForWallets
def getLedgerDelegateForWallets(self): return _CppBlockUtils.BlockDataViewer_getLedgerDelegateForWallets(self)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f81fe1044e0> >
Traceback (most recent call last):
File "ArmoryQt.py", line 6678, in method_signal
method()
File "ArmoryQt.py", line 6718, in completeBlockchainProcessingInitialization
self.setupLedgerViews()
File "ArmoryQt.py", line 6733, in setupLedgerViews
self.ledgerModel.setLedgerDelegate(TheBDM.bdv().getLedgerDelegateForWallets())
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1247, in getLedgerDelegateForWallets
def getLedgerDelegateForWallets(self): return _CppBlockUtils.BlockDataViewer_getLedgerDelegateForWallets(self)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f81fe1044e0> >
And a dialog with The DB has returned the following error:
invalid magic word
Armory will not shutdown.
Also, a few notes. That dialog message above should read "Armory will now shutdown". And this line: https://github.com/goatpig/BitcoinArmory/blob/dev/SDM.py#L458 should be "pargs" and not "pars"
Edit: Why port 9050? AFAIK this makes it impossible to use Tor since Tor also uses port 9050 by default.
Title: Re: Armory 0.95 testing phase
Post by: bitpop on July 26, 2016, 09:21:47 AM
Thanks. Is .94.1 compatible with core .13?
Title: Re: Armory 0.95 testing phase
Post by: mocacinno on July 26, 2016, 09:47:42 AM
Builds perfectly on Ubuntu 14.04.4 LTS using core 0.12.1. I can confirm the errors knightdk saw tough, altough armory didn't shut itself down (yet), it just kept on "preparing the database" untill i shut it down myself /home/bitcoin/armorydemo/BitcoinArmory/armoryengine/Transaction.py:2657: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
No systemtrayicon available
-ERROR - 1469526445: (SwigClient.cpp:58) unexpected return value
(ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 6678, in method_signal
method()
File "ArmoryQt.py", line 6716, in completeBlockchainProcessingInitialization
self.setupBDV()
File "ArmoryQt.py", line 6689, in setupBDV
TheBDM.registerBDV()
File "/home/bitcoin/armorydemo/BitcoinArmory/armoryengine/BDM.py", line 181, in registerBDV
self.bdv_.registerWithDB(MAGIC_BYTES)
File "/home/bitcoin/armorydemo/BitcoinArmory/CppBlockUtils.py", line 1251, in registerWithDB
def registerWithDB(self, *args): return _CppBlockUtils.BlockDataViewer_registerWithDB(self, *args)
RuntimeError: unexpected return value
Traceback (most recent call last):
File "ArmoryQt.py", line 6678, in method_signal
method()
File "ArmoryQt.py", line 6716, in completeBlockchainProcessingInitialization
self.setupBDV()
File "ArmoryQt.py", line 6689, in setupBDV
TheBDM.registerBDV()
File "/home/bitcoin/armorydemo/BitcoinArmory/armoryengine/BDM.py", line 181, in registerBDV
self.bdv_.registerWithDB(MAGIC_BYTES)
File "/home/bitcoin/armorydemo/BitcoinArmory/CppBlockUtils.py", line 1251, in registerWithDB
def registerWithDB(self, *args): return _CppBlockUtils.BlockDataViewer_registerWithDB(self, *args)
RuntimeError: unexpected return value
Thanks :)
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 26, 2016, 06:58:26 PM
Thanks. Is .94.1 compatible with core .13?
Can't think of a reason why not. Don't think Bitcoin Core is expected to break compatibility in any intended way in the near future, but you never know about unintendeds popping up (like having to change to stricter signature acceptance at least twice). But 0.13 should be okay. Back everything up anyway etc if you try it, unknown territory regardless. Re: 0.95 testing Same as mocacinno and knightdk, pretty much. My command prompt error output is a little different, but very similar. Armory GUI loads, but fails to begin any meaningful Db work, although some initial files are created for the database. Debian 8.5 running on Qubes.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 26, 2016, 07:12:35 PM
Thanks. Is .94.1 compatible with core .13?
Can't think of a reason why not. Don't think Bitcoin Core is expected to break compatibility in any intended way in the near future, but you never know about unintendeds popping up (like having to change to stricter signature acceptance at least twice). But 0.13 should be okay. Back everything up anyway etc if you try it, unknown territory regardless. Actually segwit will break compatibility once it is deployed (so 0.13.1 and 0.12.2 and everything later). This is due to a change in transaction serialization which will cause all current versions of Armory to break with segwit. This is being fixed with my segwit compatibility PR (https://github.com/goatpig/BitcoinArmory/pull/47) that goatpig is reviewing and will probably go into 0.95.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 26, 2016, 08:07:07 PM
Every body please start the DB on its own, see what it has to say for itself. The binary is called ArmoryDB, resides in the root project folder (where ArmoryQt.py is) and takes essentially the same set of command line arguments as the client. Say, to start the DB in testnet with the default folder paths, just do
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 26, 2016, 08:17:56 PM
Every body please start the DB on its own, see what it has to say for itself. The binary is called ArmoryDB, resides in the root project folder (where ArmoryQt.py is) and takes essentially the same set of command line arguments as the client. Say, to start the DB in testnet with the default folder paths, just do This is the output of that command: /home/andy
-INFO - 1469564234: (main.cpp:30) Running on 8 threads
-INFO - 1469564234: (main.cpp:31) Ram usage level: 4
-INFO - 1469564234: (BlockUtils.cpp:1195) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1469564234: (BlockUtils.cpp:1196) lmdb dir: /home/andy/.armory/testnet3/databases
-INFO - 1469564234: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469564234: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
bind/listen: Address already in use
Edit, actually for some reason ArmoryDB was already running beforehand for some reason, I don't know why. I just ran that command again and it is fine. Edit2: ArmoryQt.py works when the DB run separately. Edit3: So it looks like the problem I was having might be that the DB wasn't starting in testnet mode, even though I ran the normal command in testnet mode. I just did the DB in testnet and Qt not, and I got the same error.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 26, 2016, 09:11:51 PM
Edit3: So it looks like the problem I was having might be that the DB wasn't starting in testnet mode, even though I ran the normal command in testnet mode. I just did the DB in testnet and Qt not, and I got the same error.
Most likely chocking on arg parsing. Will look into it.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 26, 2016, 09:43:09 PM
Actually segwit will break compatibility once it is deployed (so 0.13.1 and 0.12.2 and everything later). This is due to a change in transaction serialization which will cause all current versions of Armory to break with segwit. This is being fixed with my segwit compatibility PR (https://github.com/goatpig/BitcoinArmory/pull/47) that goatpig is reviewing and will probably go into 0.95.
Ah, much appreciated you've already dealt with it. I'd assumed it was the same back-compatibility issues Core users face (i.e. witness tx are unavailable, but witness users can still send and receive p2pkh/p2sh to pre-witness wallets and vice-versa) Executing ./ArmoryDB yields this: -DEBUG - 1469567562: (Blockchain.cpp:232) Organizing chain
-INFO - 1469567562: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.006948s
-INFO - 1469567562: (BlockUtils.cpp:1497) Enabling zero-conf tracking
Host localhost has multiple addresses ---
you must choose one explicitly!!! What's my argument for specifying localhost for ArmoryDB?
Title: Re: Armory 0.95 testing phase
Post by: T-rage_11 on July 26, 2016, 10:01:39 PM
hi,
I'm using a old Windows XP 32-bit machine for Armory v0.92.3 cold storage ..
Can I still use the offline machine with newer online versions (0.94 and 0.95) ?
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 26, 2016, 10:19:06 PM
Ah, much appreciated you've already dealt with it. I'd assumed it was the same back-compatibility issues Core users face (i.e. witness tx are unavailable, but witness users can still send and receive p2pkh/p2sh to pre-witness wallets and vice-versa)
Both 0.93 and 0.94 could be patched to ignore SW tx (like any non SW compliant client should, it's a soft fork after all). However I don't think anyone wants to go down that path. 0.95 will properly scan SW tx at the very least. Executing ./ArmoryDB yields this: -DEBUG - 1469567562: (Blockchain.cpp:232) Organizing chain
-INFO - 1469567562: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.006948s
-INFO - 1469567562: (BlockUtils.cpp:1497) Enabling zero-conf tracking
Host localhost has multiple addresses ---
you must choose one explicitly!!! What's my argument for specifying localhost for ArmoryDB? Ahh, this thing again. First, the DB is hardcoded to listen to localhost:9050. You can't make it listen to another IP (ill add custom ports at some point). If you want to enable the DB to serve remote clients, you need to set a http daemon to connect to it over the FCGI protocol (same as how stuff like PHP interface with a web stack) and manage the network parameters around the daemon, not the ArmoryDB per se. The issue you are seeing seems to be common to Linux. I ran into it when I first started implementing around the FCGI library. It appears localhost is bound both in IPv4 or IPv6, and the fcgi lib uses listen in an old enough way that it doesn't try to distinguish between the two. At first I took that for a quirk of my debian install (it's quite aged), researched the issue and fixed it fairly quickly (something to do with /etc/hosts file maybe? can't remember). If you are hitting this error too, it seems this setup is more of a default than a stand alone case. I will setup a fresh VM, check against that, and most likely fix the FCGI lib directly.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 26, 2016, 10:27:59 PM
hi,
I'm using a old Windows XP 32-bit machine for Armory v0.92.3 cold storage ..
Can I still use the offline machine with newer online versions (0.94 and 0.95) ?
Yes
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 26, 2016, 10:34:10 PM
The behavior is kind of inconsistent. Sometimes it works, sometimes it doesn't. Usually it doesn't.
You should also fix that "pars" "pargs" thing. I think it prevents the db from being launched by qt.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 26, 2016, 10:39:34 PM
The behavior is kind of inconsistent. Sometimes it works, sometimes it doesn't. Usually it doesn't.
You should also fix that "pars" "pargs" thing. I think it prevents the db from being launched by qt.
Fixed the typos, will bundle a more consistent fix tomorrow
Title: Re: Armory 0.95 testing phase
Post by: mocacinno on July 27, 2016, 06:16:37 AM
Ahh, this thing again.
First, the DB is hardcoded to listen to localhost:9050. You can't make it listen to another IP (ill add custom ports at some point). If you want to enable the DB to serve remote clients, you need to set a http daemon to connect to it over the FCGI protocol (same as how stuff like PHP interface with a web stack) and manage the network parameters around the daemon, not the ArmoryDB per se.
The issue you are seeing seems to be common to Linux. I ran into it when I first started implementing around the FCGI library. It appears localhost is bound both in IPv4 or IPv6, and the fcgi lib uses listen in an old enough way that it doesn't try to distinguish between the two.
At first I took that for a quirk of my debian install (it's quite aged), researched the issue and fixed it fairly quickly (something to do with /etc/hosts file maybe? can't remember).
If you are hitting this error too, it seems this setup is more of a default than a stand alone case. I will setup a fresh VM, check against that, and most likely fix the FCGI lib directly.
I'll also be waiting on this fix, had the same problem as Carlton Banks, so i cannot proceed to testing either :)
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 27, 2016, 07:47:38 PM
I'll also be waiting on this fix, had the same problem as Carlton Banks, so i cannot proceed to testing either :)
Was stupid, should be fixed now.
Title: Re: Armory 0.95 testing phase
Post by: mocacinno on July 28, 2016, 07:00:49 AM
I'll also be waiting on this fix, had the same problem as Carlton Banks, so i cannot proceed to testing either :)
Was stupid, should be fixed now. Seems like the problem is fixed, altough i can't manage to get ArmoryDB running, seems like it can't bind... I'll see if i can find out what's wrong when i get home from work. ./ArmoryDB --testnet
/home/bitcoin
-INFO - 1469689140: (main.cpp:30) Running on 8 threads
-INFO - 1469689140: (main.cpp:31) Ram usage level: 4
-INFO - 1469689140: (BlockUtils.cpp:1195) blkfile dir: /home/bitcoin/.bitcoin/testnet3/blocks
-INFO - 1469689140: (BlockUtils.cpp:1196) lmdb dir: /home/bitcoin/.armory/testnet3/databases
-INFO - 1469689140: (lmdb_wrapper.cpp:388) Opening databases...
bind/listen: Address already in use
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 28, 2016, 11:33:33 AM
I'll also be waiting on this fix, had the same problem as Carlton Banks, so i cannot proceed to testing either :)
Was stupid, should be fixed now. Seems like the problem is fixed, altough i can't manage to get ArmoryDB running, seems like it can't bind... I'll see if i can find out what's wrong when i get home from work. ./ArmoryDB --testnet
/home/bitcoin
-INFO - 1469689140: (main.cpp:30) Running on 8 threads
-INFO - 1469689140: (main.cpp:31) Ram usage level: 4
-INFO - 1469689140: (BlockUtils.cpp:1195) blkfile dir: /home/bitcoin/.bitcoin/testnet3/blocks
-INFO - 1469689140: (BlockUtils.cpp:1196) lmdb dir: /home/bitcoin/.armory/testnet3/databases
-INFO - 1469689140: (lmdb_wrapper.cpp:388) Opening databases...
bind/listen: Address already in use
Could possibly mean it's already running. I'll add some more verbose and checks
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 28, 2016, 12:42:53 PM
I'll also be waiting on this fix, had the same problem as Carlton Banks, so i cannot proceed to testing either :)
Was stupid, should be fixed now. Seems like the problem is fixed, altough i can't manage to get ArmoryDB running, seems like it can't bind... I'll see if i can find out what's wrong when i get home from work. ./ArmoryDB --testnet
/home/bitcoin
-INFO - 1469689140: (main.cpp:30) Running on 8 threads
-INFO - 1469689140: (main.cpp:31) Ram usage level: 4
-INFO - 1469689140: (BlockUtils.cpp:1195) blkfile dir: /home/bitcoin/.bitcoin/testnet3/blocks
-INFO - 1469689140: (BlockUtils.cpp:1196) lmdb dir: /home/bitcoin/.armory/testnet3/databases
-INFO - 1469689140: (lmdb_wrapper.cpp:388) Opening databases...
bind/listen: Address already in use
Could possibly mean it's already running. I'll add some more verbose and checks Sometimes ArmoryDB does close when ArmoryQt crashes, so it is likely that is what happened. mocacinno, check your processes to see if ArmoryDB is still running, and if it is, kill it.
Title: Re: Armory 0.95 testing phase
Post by: mocacinno on July 28, 2016, 01:15:39 PM
Sometimes ArmoryDB does close when ArmoryQt crashes, so it is likely that is what happened.
mocacinno, check your processes to see if ArmoryDB is still running, and if it is, kill it.
I'll do that when i get home in a couple of hours (i quickly tried out the fixes this morning before leaving for work... I just copy/pasted the output/errors without thinking it thru). I'll see if ArmoryDB is already running, kill it, try again and report back :)
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 28, 2016, 11:16:42 PM
I'm getting a handful of these errors, followed by segfault: -ERROR - 1469735393: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9 Getting as far as tx scanning stage, sometimes the segfault struck while the block parsing was still happening.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 28, 2016, 11:49:05 PM
I'm getting a handful of these errors, followed by segfault: -ERROR - 1469735393: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9 Getting as far as tx scanning stage, sometimes the segfault struck while the block parsing was still happening. Mine does the same, although there aren't many errors. It just says that a buffer overflow was detected and then segfaults.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 28, 2016, 11:55:16 PM
I'm getting a handful of these errors, followed by segfault: -ERROR - 1469735393: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9 Getting as far as tx scanning stage, sometimes the segfault struck while the block parsing was still happening. Did you point it at an different dbdir? EDIT: also let me see dbLog.txt
Title: Re: Armory 0.95 testing phase
Post by: mocacinno on July 29, 2016, 08:33:09 AM
just some feedback: ArmoryDB wasn't running (this wasn't the cause of my previous problem), so i tried starting it with a trace... Found this line: bind(33, {sa_family=AF_INET, sin_port=htons(9050), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EAD
dup(2)
checked which process was using port 9050 with netstat -tulpn | grep 9050
turned out to be an essential process on my server, i stopped it for a (very short) while, tried starting ArmoryDB, now I get this: ./ArmoryDB
/home/bitcoin
-INFO - 1469781000: (main.cpp:30) Running on 8 threads
-INFO - 1469781000: (main.cpp:31) Ram usage level: 4
-INFO - 1469781000: (BlockUtils.cpp:1195) blkfile dir: /home/bitcoin/.bitcoin/blocks
-INFO - 1469781000: (BlockUtils.cpp:1196) lmdb dir: /home/bitcoin/.armory/databases
-INFO - 1469781000: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469781000: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
-INFO - 1469781000: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1469781007: (BitcoinP2P.cpp:687) Connected to Bitcoin node
Bus error
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 29, 2016, 09:04:55 AM
Did you point it at an different dbdir? No, using the standard ~/.armory location. satoshi-datadir is customised though EDIT: also let me see dbLog.txt
Log file opened at 1469741033: /home/user/.armory/dbLog.txt
-INFO - 1469741033: (main.cpp:24) Running on 4 threads
-INFO - 1469741033: (main.cpp:25) Ram usage level: 4
-INFO - 1469741033: (BlockUtils.cpp:1195) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 1469741033: (BlockUtils.cpp:1196) lmdb dir: /home/user/.armory/databases
-INFO - 1469741033: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469741033: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
-INFO - 1469741033: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469741033: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469741033: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1469741033: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469741034: (BitcoinP2P.cpp:687) Connected to Bitcoin node
-INFO - 1469741034: (BDM_Server.cpp:571) registered bdv: a083cb49093ba183c232
-INFO - 1469741113: (DatabaseBuilder.cpp:227) parsed block file #0
-INFO - 1469741156: (DatabaseBuilder.cpp:227) parsed block file #4
-INFO - 1469741185: (DatabaseBuilder.cpp:227) parsed block file #8
-INFO - 1469741215: (DatabaseBuilder.cpp:227) parsed block file #12
-INFO - 1469741245: (DatabaseBuilder.cpp:227) parsed block file #16
-INFO - 1469741277: (DatabaseBuilder.cpp:227) parsed block file #20
-INFO - 1469741306: (DatabaseBuilder.cpp:227) parsed block file #24
-INFO - 1469741337: (DatabaseBuilder.cpp:227) parsed block file #28
-INFO - 1469741368: (DatabaseBuilder.cpp:227) parsed block file #32
-INFO - 1469741403: (DatabaseBuilder.cpp:227) parsed block file #36
-INFO - 1469741427: (DatabaseBuilder.cpp:227) parsed block file #40
-INFO - 1469741461: (DatabaseBuilder.cpp:227) parsed block file #44
-INFO - 1469741492: (DatabaseBuilder.cpp:227) parsed block file #48
-INFO - 1469741523: (DatabaseBuilder.cpp:227) parsed block file #52
-INFO - 1469741552: (DatabaseBuilder.cpp:227) parsed block file #56
-INFO - 1469741583: (DatabaseBuilder.cpp:227) parsed block file #60
-INFO - 1469741614: (DatabaseBuilder.cpp:227) parsed block file #64
-INFO - 1469741641: (DatabaseBuilder.cpp:227) parsed block file #68
-INFO - 1469741667: (DatabaseBuilder.cpp:227) parsed block file #72
-INFO - 1469741693: (DatabaseBuilder.cpp:227) parsed block file #76
-INFO - 1469741721: (DatabaseBuilder.cpp:227) parsed block file #80
-INFO - 1469741746: (DatabaseBuilder.cpp:227) parsed block file #84
-INFO - 1469741775: (DatabaseBuilder.cpp:227) parsed block file #88
-INFO - 1469741805: (DatabaseBuilder.cpp:227) parsed block file #92
-INFO - 1469741837: (DatabaseBuilder.cpp:227) parsed block file #96
-INFO - 1469741871: (DatabaseBuilder.cpp:227) parsed block file #100
-INFO - 1469741904: (DatabaseBuilder.cpp:227) parsed block file #104
-INFO - 1469741934: (DatabaseBuilder.cpp:227) parsed block file #108
-INFO - 1469741962: (DatabaseBuilder.cpp:227) parsed block file #112
-INFO - 1469741992: (DatabaseBuilder.cpp:227) parsed block file #116
-INFO - 1469742023: (DatabaseBuilder.cpp:227) parsed block file #120
-INFO - 1469742058: (DatabaseBuilder.cpp:227) parsed block file #124
-INFO - 1469742092: (DatabaseBuilder.cpp:227) parsed block file #128
-INFO - 1469742120: (DatabaseBuilder.cpp:227) parsed block file #132
-INFO - 1469742152: (DatabaseBuilder.cpp:227) parsed block file #136
-INFO - 1469742185: (DatabaseBuilder.cpp:227) parsed block file #140
-INFO - 1469742217: (DatabaseBuilder.cpp:227) parsed block file #144
-INFO - 1469742243: (DatabaseBuilder.cpp:227) parsed block file #148
-INFO - 1469742269: (DatabaseBuilder.cpp:227) parsed block file #152
-INFO - 1469742296: (DatabaseBuilder.cpp:227) parsed block file #156
-INFO - 1469742322: (DatabaseBuilder.cpp:227) parsed block file #160
-INFO - 1469742350: (DatabaseBuilder.cpp:227) parsed block file #164
-INFO - 1469742378: (DatabaseBuilder.cpp:227) parsed block file #168
-INFO - 1469742404: (DatabaseBuilder.cpp:227) parsed block file #172
-INFO - 1469742427: (DatabaseBuilder.cpp:227) parsed block file #176
-INFO - 1469742453: (DatabaseBuilder.cpp:227) parsed block file #180
-INFO - 1469742478: (DatabaseBuilder.cpp:227) parsed block file #184
-INFO - 1469742502: (DatabaseBuilder.cpp:227) parsed block file #188
-INFO - 1469742528: (DatabaseBuilder.cpp:227) parsed block file #192
-INFO - 1469742552: (DatabaseBuilder.cpp:227) parsed block file #196
-INFO - 1469742574: (DatabaseBuilder.cpp:227) parsed block file #200
-INFO - 1469742597: (DatabaseBuilder.cpp:227) parsed block file #204
-INFO - 1469742620: (DatabaseBuilder.cpp:227) parsed block file #208
-INFO - 1469742642: (DatabaseBuilder.cpp:227) parsed block file #212
-INFO - 1469742669: (DatabaseBuilder.cpp:227) parsed block file #216
-INFO - 1469742691: (DatabaseBuilder.cpp:227) parsed block file #220
-INFO - 1469742714: (DatabaseBuilder.cpp:227) parsed block file #224
-INFO - 1469742733: (DatabaseBuilder.cpp:227) parsed block file #228
-INFO - 1469742754: (DatabaseBuilder.cpp:227) parsed block file #232
-INFO - 1469742774: (DatabaseBuilder.cpp:227) parsed block file #236
-INFO - 1469742795: (DatabaseBuilder.cpp:227) parsed block file #240
-INFO - 1469742819: (DatabaseBuilder.cpp:227) parsed block file #244
-INFO - 1469742840: (DatabaseBuilder.cpp:227) parsed block file #248
-INFO - 1469742862: (DatabaseBuilder.cpp:227) parsed block file #252
-INFO - 1469742886: (DatabaseBuilder.cpp:227) parsed block file #256
-INFO - 1469742910: (DatabaseBuilder.cpp:227) parsed block file #260
-INFO - 1469742932: (DatabaseBuilder.cpp:227) parsed block file #264
-INFO - 1469742959: (DatabaseBuilder.cpp:227) parsed block file #268
-INFO - 1469742981: (DatabaseBuilder.cpp:227) parsed block file #272
-INFO - 1469743011: (DatabaseBuilder.cpp:227) parsed block file #276
-INFO - 1469743033: (DatabaseBuilder.cpp:227) parsed block file #280
-INFO - 1469743057: (DatabaseBuilder.cpp:227) parsed block file #284
-INFO - 1469743081: (DatabaseBuilder.cpp:227) parsed block file #288
-INFO - 1469743105: (DatabaseBuilder.cpp:227) parsed block file #292
-INFO - 1469743128: (DatabaseBuilder.cpp:227) parsed block file #296
-INFO - 1469743150: (DatabaseBuilder.cpp:227) parsed block file #300
-INFO - 1469743173: (DatabaseBuilder.cpp:227) parsed block file #304
-INFO - 1469743193: (DatabaseBuilder.cpp:227) parsed block file #308
-INFO - 1469743218: (DatabaseBuilder.cpp:227) parsed block file #312
-INFO - 1469743242: (DatabaseBuilder.cpp:227) parsed block file #316
-INFO - 1469743263: (DatabaseBuilder.cpp:227) parsed block file #320
-INFO - 1469743289: (DatabaseBuilder.cpp:227) parsed block file #324
-INFO - 1469743312: (DatabaseBuilder.cpp:227) parsed block file #328
-INFO - 1469743330: (DatabaseBuilder.cpp:227) parsed block file #332
-INFO - 1469743355: (DatabaseBuilder.cpp:227) parsed block file #336
-INFO - 1469743377: (DatabaseBuilder.cpp:227) parsed block file #340
-INFO - 1469743401: (DatabaseBuilder.cpp:227) parsed block file #344
-INFO - 1469743421: (DatabaseBuilder.cpp:227) parsed block file #348
-INFO - 1469743445: (DatabaseBuilder.cpp:227) parsed block file #352
-INFO - 1469743469: (DatabaseBuilder.cpp:227) parsed block file #356
-INFO - 1469743492: (DatabaseBuilder.cpp:227) parsed block file #360
-INFO - 1469743515: (DatabaseBuilder.cpp:227) parsed block file #364
-INFO - 1469743538: (DatabaseBuilder.cpp:227) parsed block file #368
-INFO - 1469743563: (DatabaseBuilder.cpp:227) parsed block file #372
-INFO - 1469743585: (DatabaseBuilder.cpp:227) parsed block file #376
-INFO - 1469743607: (DatabaseBuilder.cpp:227) parsed block file #380
-INFO - 1469743631: (DatabaseBuilder.cpp:227) parsed block file #384
-INFO - 1469743655: (DatabaseBuilder.cpp:227) parsed block file #388
-INFO - 1469743676: (DatabaseBuilder.cpp:227) parsed block file #392
-INFO - 1469743702: (DatabaseBuilder.cpp:227) parsed block file #396
-INFO - 1469743725: (DatabaseBuilder.cpp:227) parsed block file #400
-INFO - 1469743747: (DatabaseBuilder.cpp:227) parsed block file #404
-INFO - 1469743772: (DatabaseBuilder.cpp:227) parsed block file #408
-INFO - 1469743793: (DatabaseBuilder.cpp:227) parsed block file #412
-INFO - 1469743819: (DatabaseBuilder.cpp:227) parsed block file #416
-INFO - 1469743840: (DatabaseBuilder.cpp:227) parsed block file #420
-INFO - 1469743861: (DatabaseBuilder.cpp:227) parsed block file #424
-INFO - 1469743884: (DatabaseBuilder.cpp:227) parsed block file #428
-INFO - 1469743907: (DatabaseBuilder.cpp:227) parsed block file #432
-INFO - 1469743929: (DatabaseBuilder.cpp:227) parsed block file #436
-INFO - 1469743955: (DatabaseBuilder.cpp:227) parsed block file #440
-INFO - 1469743980: (DatabaseBuilder.cpp:227) parsed block file #444
-INFO - 1469744006: (DatabaseBuilder.cpp:227) parsed block file #448
-INFO - 1469744027: (DatabaseBuilder.cpp:227) parsed block file #452
-INFO - 1469744050: (DatabaseBuilder.cpp:227) parsed block file #456
-INFO - 1469744071: (DatabaseBuilder.cpp:227) parsed block file #460
-INFO - 1469744094: (DatabaseBuilder.cpp:227) parsed block file #464
-INFO - 1469744121: (DatabaseBuilder.cpp:227) parsed block file #468
-INFO - 1469744148: (DatabaseBuilder.cpp:227) parsed block file #472
-INFO - 1469744168: (DatabaseBuilder.cpp:227) parsed block file #476
-INFO - 1469744192: (DatabaseBuilder.cpp:227) parsed block file #480
-INFO - 1469744221: (DatabaseBuilder.cpp:227) parsed block file #484
-INFO - 1469744228: (DatabaseBuilder.cpp:409) Found next block after skipping 0bytes
-INFO - 1469744246: (DatabaseBuilder.cpp:227) parsed block file #488
-INFO - 1469744273: (DatabaseBuilder.cpp:227) parsed block file #492
-INFO - 1469744301: (DatabaseBuilder.cpp:227) parsed block file #496
-INFO - 1469744331: (DatabaseBuilder.cpp:227) parsed block file #500
-INFO - 1469744358: (DatabaseBuilder.cpp:227) parsed block file #504
-INFO - 1469744387: (DatabaseBuilder.cpp:227) parsed block file #508
-INFO - 1469744415: (DatabaseBuilder.cpp:227) parsed block file #512
-INFO - 1469744445: (DatabaseBuilder.cpp:227) parsed block file #516
-INFO - 1469744475: (DatabaseBuilder.cpp:227) parsed block file #520
-INFO - 1469744499: (DatabaseBuilder.cpp:227) parsed block file #524
-INFO - 1469744526: (DatabaseBuilder.cpp:227) parsed block file #528
-INFO - 1469744556: (DatabaseBuilder.cpp:227) parsed block file #532
-INFO - 1469744578: (DatabaseBuilder.cpp:227) parsed block file #536
-INFO - 1469744601: (DatabaseBuilder.cpp:227) parsed block file #540
-INFO - 1469744626: (DatabaseBuilder.cpp:227) parsed block file #544
-INFO - 1469744650: (DatabaseBuilder.cpp:227) parsed block file #548
-INFO - 1469744672: (DatabaseBuilder.cpp:227) parsed block file #552
-INFO - 1469744697: (DatabaseBuilder.cpp:227) parsed block file #556
-INFO - 1469744720: (DatabaseBuilder.cpp:227) parsed block file #560
-INFO - 1469744751: (DatabaseBuilder.cpp:227) parsed block file #564
-INFO - 1469744773: (DatabaseBuilder.cpp:227) parsed block file #568
-INFO - 1469744793: (DatabaseBuilder.cpp:227) parsed block file #572
-INFO - 1469744818: (DatabaseBuilder.cpp:227) parsed block file #576
-INFO - 1469744831: (DatabaseBuilder.cpp:227) parsed block file #580
-DEBUG - 1469744831: (Blockchain.cpp:232) Organizing chain
-INFO - 1469744851: (DatabaseBuilder.cpp:53) updated HEADERS db in 3818s
-INFO - 1469744851: (BlockUtils.cpp:1497) Enabling zero-conf tracking
-INFO - 1469744852: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469744879: (BlockchainScanner.cpp:640) scanned from height #0 to #142648
-INFO - 1469744901: (BlockchainScanner.cpp:640) scanned from height #142649 to #169936
-INFO - 1469744918: (BlockchainScanner.cpp:640) scanned from height #169937 to #183098
-INFO - 1469744936: (BlockchainScanner.cpp:640) scanned from height #183099 to #189198
-INFO - 1469744955: (BlockchainScanner.cpp:640) scanned from height #189199 to #194856
-INFO - 1469744972: (BlockchainScanner.cpp:640) scanned from height #194857 to #200839
-INFO - 1469744990: (BlockchainScanner.cpp:640) scanned from height #200840 to #206610
-INFO - 1469745008: (BlockchainScanner.cpp:640) scanned from height #206611 to #211790
-INFO - 1469745024: (BlockchainScanner.cpp:640) scanned from height #211791 to #215978
Log file opened at 1469745259: /home/user/.armory/dbLog.txt
-INFO - 1469745259: (main.cpp:24) Running on 4 threads
-INFO - 1469745259: (main.cpp:25) Ram usage level: 4
-INFO - 1469745259: (BlockUtils.cpp:1195) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 1469745259: (BlockUtils.cpp:1196) lmdb dir: /home/user/.armory/databases
-INFO - 1469745259: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469745259: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
-INFO - 1469745259: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1469745260: (BitcoinP2P.cpp:687) Connected to Bitcoin node
-INFO - 1469745260: (BDM_Server.cpp:571) registered bdv: 90a78d345aa0a3dfef2e
-INFO - 1469745276: (DatabaseBuilder.cpp:199) Found 422663 headers in db
-INFO - 1469745284: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469745288: (DatabaseBuilder.cpp:409) Found next block after skipping 676822bytes
-INFO - 1469745291: (DatabaseBuilder.cpp:227) parsed block file #582
-DEBUG - 1469745291: (Blockchain.cpp:232) Organizing chain
-INFO - 1469745291: (DatabaseBuilder.cpp:53) updated HEADERS db in 3.62354s
-INFO - 1469745291: (BlockUtils.cpp:1497) Enabling zero-conf tracking
Log file opened at 1469747449: /home/user/.armory/dbLog.txt
-INFO - 1469747449: (main.cpp:24) Running on 4 threads
-INFO - 1469747449: (main.cpp:25) Ram usage level: 4
-INFO - 1469747449: (BlockUtils.cpp:1195) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 1469747449: (BlockUtils.cpp:1196) lmdb dir: /home/user/.armory/databases
-INFO - 1469747449: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469747449: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
-INFO - 1469747450: (BitcoinP2P.cpp:687) Connected to Bitcoin node
-INFO - 1469747450: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1469747450: (BDM_Server.cpp:571) registered bdv: 623907bdf363b5bce9d7
-INFO - 1469747463: (DatabaseBuilder.cpp:199) Found 422663 headers in db
-INFO - 1469747469: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469747470: (DatabaseBuilder.cpp:409) Found next block after skipping 676822bytes
-INFO - 1469747472: (DatabaseBuilder.cpp:227) parsed block file #582
-DEBUG - 1469747472: (Blockchain.cpp:232) Organizing chain
-INFO - 1469747472: (DatabaseBuilder.cpp:53) updated HEADERS db in 2.97311s
-INFO - 1469747472: (BlockUtils.cpp:1497) Enabling zero-conf tracking
-INFO - 1469747472: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469747511: (BlockchainScanner.cpp:640) scanned from height #0 to #142648
-INFO - 1469747529: (BlockchainScanner.cpp:640) scanned from height #142649 to #169936
-INFO - 1469747553: (BlockchainScanner.cpp:640) scanned from height #169937 to #183098
-INFO - 1469747585: (BlockchainScanner.cpp:640) scanned from height #183099 to #189198
-INFO - 1469747590: (BlockchainScanner.cpp:51) no history to scan
-INFO - 1469747604: (BlockchainScanner.cpp:640) scanned from height #189199 to #194856
-INFO - 1469747628: (BlockchainScanner.cpp:640) scanned from height #194857 to #200839
-INFO - 1469747645: (BlockchainScanner.cpp:640) scanned from height #200840 to #206610
-INFO - 1469747666: (BlockchainScanner.cpp:640) scanned from height #206611 to #211790
-INFO - 1469747680: (BlockchainScanner.cpp:640) scanned from height #211791 to #215978
-INFO - 1469747692: (BlockchainScanner.cpp:640) scanned from height #215979 to #219364
-INFO - 1469747705: (BlockchainScanner.cpp:640) scanned from height #219365 to #222839
-INFO - 1469747719: (BlockchainScanner.cpp:640) scanned from height #222840 to #225967
-INFO - 1469747733: (BlockchainScanner.cpp:640) scanned from height #225968 to #229667
-INFO - 1469747751: (BlockchainScanner.cpp:640) scanned from height #229668 to #232781
-INFO - 1469747766: (BlockchainScanner.cpp:640) scanned from height #232782 to #235928
-INFO - 1469747780: (BlockchainScanner.cpp:640) scanned from height #235929 to #239242
-INFO - 1469747793: (BlockchainScanner.cpp:640) scanned from height #239243 to #243433
-INFO - 1469747809: (BlockchainScanner.cpp:640) scanned from height #243434 to #248498
-INFO - 1469747824: (BlockchainScanner.cpp:640) scanned from height #248499 to #252855
-INFO - 1469747840: (BlockchainScanner.cpp:640) scanned from height #252856 to #256752
-INFO - 1469747852: (BlockchainScanner.cpp:640) scanned from height #256753 to #260951
-INFO - 1469747868: (BlockchainScanner.cpp:640) scanned from height #260952 to #265182
-INFO - 1469747886: (BlockchainScanner.cpp:640) scanned from height #265183 to #268923
-INFO - 1469747901: (BlockchainScanner.cpp:640) scanned from height #268924 to #271643
-INFO - 1469747914: (BlockchainScanner.cpp:640) scanned from height #271644 to #274279
-INFO - 1469747930: (BlockchainScanner.cpp:640) scanned from height #274280 to #277415
-INFO - 1469747943: (BlockchainScanner.cpp:640) scanned from height #277416 to #280711
-INFO - 1469747957: (BlockchainScanner.cpp:640) scanned from height #280712 to #283774
-INFO - 1469747969: (BlockchainScanner.cpp:640) scanned from height #283775 to #286388
-INFO - 1469747982: (BlockchainScanner.cpp:640) scanned from height #286389 to #288717
-INFO - 1469747995: (BlockchainScanner.cpp:640) scanned from height #288718 to #290821
-INFO - 1469748007: (BlockchainScanner.cpp:640) scanned from height #290822 to #293339
-INFO - 1469748020: (BlockchainScanner.cpp:640) scanned from height #293340 to #295877
Log file opened at 1469748450: /home/user/.armory/dbLog.txt
-INFO - 1469748450: (main.cpp:24) Running on 4 threads
-INFO - 1469748450: (main.cpp:25) Ram usage level: 4
-INFO - 1469748450: (BlockUtils.cpp:1195) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 1469748450: (BlockUtils.cpp:1196) lmdb dir: /home/user/.armory/databases
-INFO - 1469748450: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469748451: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
-INFO - 1469748451: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1469748451: (BitcoinP2P.cpp:687) Connected to Bitcoin node
-INFO - 1469748451: (BDM_Server.cpp:571) registered bdv: 00dddb35876377a99df6
-INFO - 1469748463: (DatabaseBuilder.cpp:199) Found 422668 headers in db
-INFO - 1469748470: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469748472: (DatabaseBuilder.cpp:409) Found next block after skipping 705598bytes
-INFO - 1469748474: (DatabaseBuilder.cpp:227) parsed block file #582
-DEBUG - 1469748474: (Blockchain.cpp:232) Organizing chain
-INFO - 1469748474: (DatabaseBuilder.cpp:53) updated HEADERS db in 2.68421s
-INFO - 1469748474: (BlockUtils.cpp:1497) Enabling zero-conf tracking
-INFO - 1469748475: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469748511: (BlockchainScanner.cpp:640) scanned from height #0 to #142648
-INFO - 1469748531: (BlockchainScanner.cpp:640) scanned from height #142649 to #169936
-INFO - 1469748547: (BlockchainScanner.cpp:640) scanned from height #169937 to #183098
-INFO - 1469748565: (BlockchainScanner.cpp:640) scanned from height #183099 to #189198
-INFO - 1469748587: (BlockchainScanner.cpp:640) scanned from height #189199 to #194856
-INFO - 1469748606: (BlockchainScanner.cpp:640) scanned from height #194857 to #200839
-INFO - 1469748621: (BlockchainScanner.cpp:640) scanned from height #200840 to #206610
-INFO - 1469748640: (BlockchainScanner.cpp:640) scanned from height #206611 to #211790
-INFO - 1469748659: (BlockchainScanner.cpp:640) scanned from height #211791 to #215978
-INFO - 1469748676: (BlockchainScanner.cpp:640) scanned from height #215979 to #219364
Log file opened at 1469748785: /home/user/.armory/dbLog.txt
-INFO - 1469748785: (main.cpp:24) Running on 4 threads
-INFO - 1469748785: (main.cpp:25) Ram usage level: 4
-INFO - 1469748785: (BlockUtils.cpp:1195) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 1469748785: (BlockUtils.cpp:1196) lmdb dir: /home/user/.armory/databases
-INFO - 1469748785: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469748785: (BlockUtils.cpp:1386) Executing: doInitialSyncOnLoad
-INFO - 1469748785: (BitcoinP2P.cpp:687) Connected to Bitcoin node
-INFO - 1469748785: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1469748786: (BDM_Server.cpp:571) registered bdv: e892133941234ef50898
-INFO - 1469748798: (DatabaseBuilder.cpp:199) Found 422668 headers in db
-INFO - 1469748805: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469748808: (DatabaseBuilder.cpp:409) Found next block after skipping 705598bytes
-INFO - 1469748810: (DatabaseBuilder.cpp:227) parsed block file #582
-DEBUG - 1469748810: (Blockchain.cpp:232) Organizing chain
-INFO - 1469748810: (DatabaseBuilder.cpp:53) updated HEADERS db in 3.02519s
-INFO - 1469748810: (BlockUtils.cpp:1497) Enabling zero-conf tracking
-INFO - 1469748811: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469748852: (BlockchainScanner.cpp:640) scanned from height #0 to #142648
-INFO - 1469748870: (BlockchainScanner.cpp:640) scanned from height #142649 to #169936
-INFO - 1469748884: (BlockchainScanner.cpp:640) scanned from height #169937 to #183098
-INFO - 1469748897: (BlockchainScanner.cpp:640) scanned from height #183099 to #189198
-INFO - 1469748911: (BlockchainScanner.cpp:640) scanned from height #189199 to #194856
-INFO - 1469748923: (BlockchainScanner.cpp:640) scanned from height #194857 to #200839
-INFO - 1469748936: (BlockchainScanner.cpp:640) scanned from height #200840 to #206610
-INFO - 1469748950: (BlockchainScanner.cpp:640) scanned from height #206611 to #211790
-INFO - 1469748968: (BlockchainScanner.cpp:640) scanned from height #211791 to #215978
-INFO - 1469748980: (BlockchainScanner.cpp:640) scanned from height #215979 to #219364
-INFO - 1469748994: (BlockchainScanner.cpp:640) scanned from height #219365 to #222839
-INFO - 1469749008: (BlockchainScanner.cpp:640) scanned from height #222840 to #225967
-INFO - 1469749020: (BlockchainScanner.cpp:640) scanned from height #225968 to #229667
-INFO - 1469749031: (BlockchainScanner.cpp:640) scanned from height #229668 to #232781
Seems pretty uneventful to me.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 29, 2016, 12:32:42 PM
Here is my dblog
Log file opened at 1469576952: /home/andy/.armory/regtest/dbLog.txt
-INFO - 1469576952: (main.cpp:30) Running on 8 threads
-INFO - 1469576952: (main.cpp:31) Ram usage level: 4
-INFO - 1469576952: (BlockUtils.cpp:1219) blkfile dir: /home/andy/.bitcoin/blocks
-INFO - 1469576952: (BlockUtils.cpp:1220) lmdb dir: /home/andy/.armory/regtest/databases
-INFO - 1469576952: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469576952: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469576952: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469576952: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469576952: (DatabaseBuilder.cpp:199) Found 1 headers in db
Log file opened at 1469576980: /home/andy/.armory/regtest/dbLog.txt
-INFO - 1469576980: (main.cpp:30) Running on 8 threads
-INFO - 1469576980: (main.cpp:31) Ram usage level: 4
-INFO - 1469576980: (BlockUtils.cpp:1219) blkfile dir: /home/andy/.bitcoin/blocks
-INFO - 1469576980: (BlockUtils.cpp:1220) lmdb dir: /home/andy/.armory/regtest/databases
-INFO - 1469576980: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469576980: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469576980: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469576980: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469576980: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1469576980: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1469576980: (Blockchain.cpp:232) Organizing chain
-INFO - 1469576980: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.00113s
-INFO - 1469576980: (BlockUtils.cpp:1521) Enabling zero-conf tracking
-INFO - 1469576980: (BitcoinP2P.cpp:691) Connected to Bitcoin node
Log file opened at 1469577029: /home/andy/.armory/regtest/dbLog.txt
-INFO - 1469577029: (main.cpp:30) Running on 8 threads
-INFO - 1469577029: (main.cpp:31) Ram usage level: 4
-INFO - 1469577029: (BlockUtils.cpp:1219) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1469577029: (BlockUtils.cpp:1220) lmdb dir: /home/andy/.armory/regtest/databases
-INFO - 1469577029: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469577029: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469577029: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469577029: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469577029: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1469577029: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1469577029: (Blockchain.cpp:232) Organizing chain
-INFO - 1469577029: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.000417s
-INFO - 1469577029: (BlockUtils.cpp:1521) Enabling zero-conf tracking
-INFO - 1469577034: (BDM_Server.cpp:571) registered bdv: 97bb4d41e3b42f629a93
-INFO - 1469577034: (BDM_supportClasses.cpp:387) Starting address registration process
-ERROR - 1469577034: (lmdb_wrapper.cpp:1461) Headers DB has no block at height: 0
-ERROR - 1469577034: (lmdb_wrapper.cpp:1441) No headers at height 0
Log file opened at 1469577043: /home/andy/.armory/regtest/dbLog.txt
-INFO - 1469577043: (main.cpp:30) Running on 8 threads
-INFO - 1469577043: (main.cpp:31) Ram usage level: 4
-INFO - 1469577043: (BlockUtils.cpp:1219) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1469577043: (BlockUtils.cpp:1220) lmdb dir: /home/andy/.armory/regtest/databases
-INFO - 1469577043: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469577043: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469577043: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469577043: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469577043: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1469577043: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - -INFO - 14695770431469577043: : ((BitcoinP2P.cppBlockchain.cpp::691) Connected to Bitcoin node232
-INFO - 1469577043: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.002176s
-INFO - 1469577043: (BlockUtils.cpp:1521) Enabling zero-conf tracking
-INFO - 1469577050: (BDM_Server.cpp:571) registered bdv: db2a604ec4cd038c1eeb
-INFO - 1469577050: (BDM_supportClasses.cpp:387) Starting address registration process
-ERROR - 1469577050: (lmdb_wrapper.cpp:1461) Headers DB has no block at height: 0
-ERROR - 1469577050: (lmdb_wrapper.cpp:1441) No headers at height 0
Log file opened at 1469577062: /home/andy/.armory/regtest/dbLog.txt
-INFO - 1469577062: (main.cpp:30) Running on 8 threads
-INFO - 1469577062: (main.cpp:31) Ram usage level: 4
-INFO - 1469577062: (BlockUtils.cpp:1219) blkfile dir: /media/andy/Data/Programs/Bitcoin/data/regtest/blocks
-INFO - 1469577062: (BlockUtils.cpp:1220) lmdb dir: /home/andy/.armory/regtest/databases
-INFO - 1469577062: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469577062: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469577062: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469577062: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469577062: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1469577062: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469577062: (BitcoinP2P.cpp:691) Connected to Bitcoin node
-INFO - 1469577062: (DatabaseBuilder.cpp:227) parsed block file #0
-DEBUG - 1469577062: (Blockchain.cpp:232) Organizing chain
-INFO - 1469577062: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.04775s
-INFO - 1469577062: (BlockUtils.cpp:1521) Enabling zero-conf tracking
-INFO - 1469577065: (BDM_Server.cpp:571) registered bdv: 953a6d7b2058e212dbdd
-INFO - 1469577065: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469577065: (BlockchainScanner.cpp:640) scanned from height #0 to #681
-INFO - 1469577065: (BlockchainScanner.cpp:222) scanned transaction history in 0.021318s
-INFO - 1469577065: (BlockchainScanner.cpp:640) scanned from height #681 to #681
-INFO - 1469577065: (BDM_supportClasses.cpp:498) Done with side scan of wallet
-INFO - 1469577070: (BDM_Server.cpp:602) unregistered bdv: 953a6d7b2058e212dbdd
-ERROR - 1469577070: (DataObject.h:223) exhausted entries in Arguments object
-INFO - 1469577077: (BDM_Server.cpp:571) registered bdv: d5afdcee13cacac3d529
-INFO - 1469577080: (BDM_Server.cpp:602) unregistered bdv: d5afdcee13cacac3d529
-ERROR - 1469577137: (DataObject.h:223) exhausted entries in Arguments object
-ERROR - 1469577137: (DataObject.h:223) exhausted entries in Arguments object
-ERROR - 1469577137: (DataObject.h:223) exhausted entries in Arguments object
-INFO - 1469581647: (BitcoinP2P.cpp:712) Disconnected from Bitcoin node
Log file opened at 1469721946: /home/andy/.armory/regtest/dbLog.txt
-INFO - 1469721946: (main.cpp:24) Running on 8 threads
-INFO - 1469721946: (main.cpp:25) Ram usage level: 4
-INFO - 1469721946: (BlockUtils.cpp:1219) blkfile dir: /media/andy/Data/Programs/Bitcoin/data/regtest/blocks
-INFO - 1469721946: (BlockUtils.cpp:1220) lmdb dir: /home/andy/.armory/regtest/databases
-INFO - 1469721946: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469721946: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469721946: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1469721946: (BitcoinP2P.cpp:691) Connected to Bitcoin node
-INFO - 1469721946: (DatabaseBuilder.cpp:199) Found 682 headers in db
-INFO - 1469721946: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469721946: (DatabaseBuilder.cpp:227) parsed block file #0
-DEBUG - 1469721946: (Blockchain.cpp:232) Organizing chain
-INFO - 1469721946: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.286681s
-INFO - 1469721946: (DatabaseBuilder.cpp:103) scanning new blocks from #682 to #682
-INFO - 1469721946: (BlockchainScanner.cpp:640) scanned from height #682 to #682
-INFO - 1469721946: (DatabaseBuilder.cpp:153) scanned new blocks in 0.01679s
-INFO - 1469721946: (DatabaseBuilder.cpp:157) init db in 0.309212s
-INFO - 1469721946: (BlockUtils.cpp:1521) Enabling zero-conf tracking
-INFO - 1469721947: (BDM_Server.cpp:571) registered bdv: 510cfc42b010fd290cae
-INFO - 1469721963: (BDM_Server.cpp:602) unregistered bdv: 510cfc42b010fd290cae
-INFO - 1469721963: (BDM_Server.cpp:515) proceeding to shutdown
-INFO - 1469721968: (BDM_Server.cpp:571) registered bdv: eafb083dbb49185f5236
-INFO - 1469722046: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469722046: (BlockchainScanner.cpp:640) scanned from height #0 to #682
-INFO - 1469722046: (BlockchainScanner.cpp:222) scanned transaction history in 0.121126s
-INFO - 1469722046: (BlockchainScanner.cpp:640) scanned from height #682 to #682
-INFO - 1469722046: (BDM_supportClasses.cpp:498) Done with side scan of wallet rc7Qs5f4
-INFO - 1469722066: (BitcoinP2P.cpp:712) Disconnected from Bitcoin node
I was testing both dev and my segwit branch. The database dir was the default, which should have been empty. The satoshi datadir was custom.
Also, it looks like the build_installer.bat scripts are gone.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 29, 2016, 01:16:02 PM
just some feedback: ArmoryDB wasn't running (this wasn't the cause of my previous problem), so i tried starting it with a trace... Found this line: bind(33, {sa_family=AF_INET, sin_port=htons(9050), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EAD
dup(2)
checked which process was using port 9050 with You should pull every time before you test, changed the default port to 9001 yesterday =D ---- Cartlon, knightdk: Let's isolate things a bit. Start from a fresh folder, spawn the db manually and build the testnet db. Then start the testnet client. Let's see if that works. Also, it looks like the build_installer.bat scripts are gone.
Will be fixed in next commit.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 29, 2016, 01:28:19 PM
Let's isolate things a bit. Start from a fresh folder, spawn the db manually and build the testnet db. Then start the testnet client. Let's see if that works.
So I deleted the testnet folder. Then I started the Bitcoin Core testnet. Then I started ArmoryDB. Then I started ArmoryQt.py. It started without issue. Then I turned off the auto manage bitcoind and restarted Armory. I got the following error: (ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 6681, in method_signal
method()
File "ArmoryQt.py", line 6727, in completeBlockchainProcessingInitialization
self.setupLedgerViews()
File "ArmoryQt.py", line 6745, in setupLedgerViews
self.ledgerModel.setLedgerDelegate(TheBDM.bdv().getLedgerDelegateForWallets())
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1248, in getLedgerDelegateForWallets
def getLedgerDelegateForWallets(self): return _CppBlockUtils.BlockDataViewer_getLedgerDelegateForWallets(self)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f1fd808c060> >
Traceback (most recent call last):
File "ArmoryQt.py", line 6681, in method_signal
method()
File "ArmoryQt.py", line 6727, in completeBlockchainProcessingInitialization
self.setupLedgerViews()
File "ArmoryQt.py", line 6745, in setupLedgerViews
self.ledgerModel.setLedgerDelegate(TheBDM.bdv().getLedgerDelegateForWallets())
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1248, in getLedgerDelegateForWallets
def getLedgerDelegateForWallets(self): return _CppBlockUtils.BlockDataViewer_getLedgerDelegateForWallets(self)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f1fd808c060> >
There was also an error dialog saying that it could not find the headers folder in the data directory. Looking in the data directory, the databases folder was empty. So, I restarted both the DB and Qt and now there appears to be no error.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 29, 2016, 04:50:41 PM
Testers, please pull the new code, some significant fixes in there. Also merged in achow's SegWit scan code. Scan speed should be significantly improved too, got rid of a pointless (yet very frequent) copy.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 29, 2016, 06:01:38 PM
Getting build errors with ac2eb68: g++ -Icryptopp -Imdb -IBlockDataManager/fcgi -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -std=c++11 -O2 -pipe -fPIC -c SwigClient.cpp
g++ -Icryptopp -Imdb -IBlockDataManager/fcgi -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -std=c++11 -O2 -pipe -fPIC -c StringSockets.cpp
swig -c++ -python -threads -outdir ../ -v CppBlockUtils.i
Language subdirectory: python
Search paths:
./
./swig_lib/python/
/usr/share/swig2.0/python/
./swig_lib/
/usr/share/swig2.0/
Preprocessing...
Starting language-specific parse...
BtcUtils.h:277: Error: Syntax error in input(3).
Makefile:122: recipe for target 'CppBlockUtils_wrap.cxx' failed
make[1]: *** [CppBlockUtils_wrap.cxx] Error 1
make[1]: Leaving directory '/home/user/BitcoinArmory/cppForSwig'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
Debian 8.5 under Qubes 3. It might be something quick to fix, but I'd rather work with whatever the eventual goatpig solution is.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 29, 2016, 06:15:01 PM
Getting build errors with ac2eb68: g++ -Icryptopp -Imdb -IBlockDataManager/fcgi -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -std=c++11 -O2 -pipe -fPIC -c SwigClient.cpp
g++ -Icryptopp -Imdb -IBlockDataManager/fcgi -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -std=c++11 -O2 -pipe -fPIC -c StringSockets.cpp
swig -c++ -python -threads -outdir ../ -v CppBlockUtils.i
Language subdirectory: python
Search paths:
./
./swig_lib/python/
/usr/share/swig2.0/python/
./swig_lib/
/usr/share/swig2.0/
Preprocessing...
Starting language-specific parse...
BtcUtils.h:277: Error: Syntax error in input(3).
Makefile:122: recipe for target 'CppBlockUtils_wrap.cxx' failed
make[1]: *** [CppBlockUtils_wrap.cxx] Error 1
make[1]: Leaving directory '/home/user/BitcoinArmory/cppForSwig'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
Debian 8.5 under Qubes 3. It might be something quick to fix, but I'd rather work with whatever the eventual goatpig solution is. Same error.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 29, 2016, 06:19:40 PM
SWIG choking on some new code, fixing it as we speak.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 29, 2016, 06:44:23 PM
Build should be fixed now.
Segfault is apparently triggered in new node p2p code. Consider shutting down your now when build&scanning if the segfault gets too much in the way, until I fix it.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 29, 2016, 11:04:56 PM
Well, some improvement seems to be evident. Just got through a full Db build, with hiccups. ArmoryQt quit on the job: Log file doesn't exist [yet]
(ERROR) ArmoryQt.py:1218 - 8 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:1223 - File mempool.bin does not exist. Nothing deleted.
-ERROR - 1469826343: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469826603: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469826863: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827273: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827623: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827684: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827744: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469828604: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829005: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829055: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829115: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829175: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829175: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829235: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
terminate called after throwing an instance of 'DbErrorMsg'
Aborted
Meanwhile the ArmoryDb executable kept itself afloat, and finished scanning seemingly without issues: -INFO - 1469826231: (BlockUtils.cpp:1219) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 1469826231: (BlockUtils.cpp:1220) lmdb dir: /home/user/.armory/databases
-INFO - 1469826231: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1469826231: (BlockUtils.cpp:1410) Executing: doInitialSyncOnLoad
-INFO - 1469826231: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1469826231: (lmdb_wrapper.cpp:1202) No headers in DB yet!
-INFO - 1469826231: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1469826231: (DatabaseBuilder.cpp:49) updating HEADERS db
-INFO - 1469826231: (BitcoinP2P.cpp:693) Connected to Bitcoin node
-INFO - 1469826232: (BDM_Server.cpp:571) registered bdv:
-INFO - 1469826289: (DatabaseBuilder.cpp:227) parsed block file #0
-INFO - 1469826313: (DatabaseBuilder.cpp:227) parsed block file #4
-INFO - 1469826339: (DatabaseBuilder.cpp:227) parsed block file #8
<expected results/repetition scrub>
-INFO - 1469828381: (DatabaseBuilder.cpp:227) parsed block file #476
-INFO - 1469828398: (DatabaseBuilder.cpp:227) parsed block file #480
-INFO - 1469828414: (DatabaseBuilder.cpp:227) parsed block file #484
-INFO - 1469828423: (DatabaseBuilder.cpp:409) Found next block after skipping 0bytes
-INFO - 1469828430: (DatabaseBuilder.cpp:227) parsed block file #488
-INFO - 1469828448: (DatabaseBuilder.cpp:227) parsed block file #492
-INFO - 1469828465: (DatabaseBuilder.cpp:227) parsed block file #496
<expected results/repetition scrub>
-INFO - 1469828791: (DatabaseBuilder.cpp:227) parsed block file #572
-INFO - 1469828810: (DatabaseBuilder.cpp:227) parsed block file #576
-INFO - 1469828822: (DatabaseBuilder.cpp:227) parsed block file #580
-DEBUG - 1469828824: (Blockchain.cpp:232) Organizing chain
-INFO - 1469828840: (DatabaseBuilder.cpp:53) updated HEADERS db in 5766.17s
-INFO - 1469828840: (BlockUtils.cpp:1521) Enabling zero-conf tracking
-INFO - 1469828841: (BDM_supportClasses.cpp:387) Starting address registration process
-INFO - 1469828860: (BlockchainScanner.cpp:641) scanned from height #0 to #142648
-INFO - 1469828872: (BlockchainScanner.cpp:641) scanned from height #142649 to #169936
-INFO - 1469828882: (BlockchainScanner.cpp:641) scanned from height #169937 to #183098
<expected results/repetition scrub>
-INFO - 1469829795: (BlockchainScanner.cpp:641) scanned from height #375302 to #376425
-INFO - 1469829807: (BlockchainScanner.cpp:641) scanned from height #376426 to #377591
-INFO - 1469829825: (BlockchainScanner.cpp:641) scanned from height #377592 to #378482
-INFO - 1469829834: (BlockchainScanner.cpp:51) no history to scan
-INFO - 1469829840: (BlockchainScanner.cpp:641) scanned from height #378483 to #379441
-INFO - 1469829854: (BlockchainScanner.cpp:641) scanned from height #379442 to #380397
-INFO - 1469829866: (BlockchainScanner.cpp:641) scanned from height #380398 to #381392
<expected results/repetition scrub>
-INFO - 1469830477: (BlockchainScanner.cpp:641) scanned from height #421428 to #422034
-INFO - 1469830486: (BlockchainScanner.cpp:641) scanned from height #422035 to #422668
-INFO - 1469830487: (BlockchainScanner.cpp:641) scanned from height #422669 to #422804
-INFO - 1469830487: (BlockchainScanner.cpp:223) scanned transaction history in 2121.4s
-INFO - 1469830496: (BlockchainScanner.cpp:1513) resolving txhashes
-INFO - 1469830697: (BlockchainScanner.cpp:51) no history to scan
-INFO - 1469830718: (BlockchainScanner.cpp:51) no history to scan
-INFO - 1469830806: (BlockchainScanner.cpp:1569) 93 blocks hit by tx filters
-INFO - 1469830926: (BDM_Server.cpp:571) registered bdv:
-INFO - 1469830938: (BlockchainScanner.cpp:1630) found 90 missing hashes
-INFO - 1469830938: (BlockchainScanner.cpp:1675) Resolved missing hashes in 71.789s
-INFO - 1469830938: (BlockchainScanner.cpp:641) scanned from height #422804 to #422807
-INFO - 1469830938: (BDM_supportClasses.cpp:498) Done with side scan of wallet
-INFO - 1469830938: (BDM_Server.cpp:602) unregistered bdv:
-INFO - 1469830970: (BDM_Server.cpp:602) unregistered bdv:
-ERROR - 1469830998: (DataObject.h:223) exhausted entries in Arguments object
Then tried bringing up ArmoryQt again; success, but tx history and balance/s were borked. Shut ArmoryDb and ArmoryQt, re-starting them and tx's and balance/s were present and correct. tx hashes are available where they previously weren't (spends from coinbase outputs), although I haven't yet cross-checked that any are correct. Actual coinbase tx's are still unavailable to view. Wallet Properties is missing the balances (known issue, right?) Some example armorylog.txt output from my initial nosing around... A few of these when looking at tx details: Traceback (most recent call last):
File "./ArmoryQt.py", line 3626, in dblClickLedger
self.showLedgerTx()
File "./ArmoryQt.py", line 3649, in showLedgerTx
DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
File "/home/user/BitcoinArmory/qtdialogs.py", line 5667, in __init__
self.data = extractTxInfo(pytx, txtime)
File "/home/user/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError
And dozens of this sort of thing: Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1180, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
(ERROR) Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1139, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1139, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
(ERROR) Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1123, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1123, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
(ERROR) Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1180, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 29, 2016, 11:26:14 PM
Well, some improvement seems to be evident. Just got through a full Db build, with hiccups. ArmoryQt quit on the job: Log file doesn't exist [yet]
(ERROR) ArmoryQt.py:1218 - 8 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:1223 - File mempool.bin does not exist. Nothing deleted.
-ERROR - 1469826343: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469826603: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469826863: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827273: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827623: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827684: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469827744: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469828604: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829005: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829055: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829115: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829175: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829175: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
-ERROR - 1469829235: (StringSockets.cpp:384) FcgiSocket::writeAndRead exception: select error: 9
terminate called after throwing an instance of 'DbErrorMsg'
Aborted
Fixing that as we speak Then tried bringing up ArmoryQt again; success, but tx history and balance/s were borked. Shut ArmoryDb and ArmoryQt, re-starting them and tx's and balance/s were present and correct.
Looking into that tx hashes are available where they previously weren't (spends from coinbase outputs), although I haven't yet cross-checked that any are correct. Actual coinbase tx's are still unavailable to view.
Turns out I don't have coinbase tx to look at. I'll get me a few on the testnet and look at it directly (if you have a testnet address with a coinbase reward, feel free to provide it =P) Wallet Properties is missing the balances (known issue, right?)
Yes Some example armorylog.txt output from my initial nosing around... A few of these when looking at tx details: Traceback (most recent call last):
File "./ArmoryQt.py", line 3626, in dblClickLedger
self.showLedgerTx()
File "./ArmoryQt.py", line 3649, in showLedgerTx
DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
File "/home/user/BitcoinArmory/qtdialogs.py", line 5667, in __init__
self.data = extractTxInfo(pytx, txtime)
File "/home/user/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError
And dozens of this sort of thing: Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1180, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
(ERROR) Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1139, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1139, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
(ERROR) Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1123, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1123, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
(ERROR) Traceback (most recent call last):
File "/home/user/BitcoinArmory/armorymodels.py", line 1180, in data
cppAddr = self.wlt.cppWallet.getScrAddrObjByKey(Hash160ToScrAddr(addr160))
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1178, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 57, in _swig_getattr
raise AttributeError(name)
AttributeError: getScrAddrObjByKey
Looks like known issues on that front.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 29, 2016, 11:36:52 PM
Turns out I don't have coinbase tx to look at. I'll get me a few on the testnet and look at it directly (if you have a testnet address with a coinbase reward, feel free to provide it =P)
Just use regtest and mine your own regtest coins. You'll need 0.13 though in order to mine to a specific address.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 30, 2016, 10:02:46 AM
Then tried bringing up ArmoryQt again; success, but tx history and balance/s were borked. Shut ArmoryDb and ArmoryQt, re-starting them and tx's and balance/s were present and correct.
Looking into that My explanation is a little lacking: I did not shut the ArmoryDb instance down before starting ArmoryQt again (subsequent to the "throwing DBErrorMsg" crash). So any routines that involve ArmoryQt and ArmoryDb co-operating when ArmoryQt starts up may well be unprepared for a fully initialised instance of ArmoryDb already running when ArmoryQt is executed.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 30, 2016, 11:23:20 AM
My explanation is a little lacking: I did not shut the ArmoryDb instance down before starting ArmoryQt again (subsequent to the "throwing DBErrorMsg" crash). So any routines that involve ArmoryQt and ArmoryDb co-operating when ArmoryQt starts up may well be unprepared for a fully initialised instance of ArmoryDb already running when ArmoryQt is executed.
The issues seems to be the client is messing up when dealing with data coming in into different packets (as opposed to all available in a single recv loop). I'm switching from select() to poll() and getting that dealt with.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on July 30, 2016, 01:07:49 PM
It appears that running just ArmoryQt.py without starting ArmoryDB beforehand just results in it never getting out of the "Preparing databases" stage.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 30, 2016, 03:56:07 PM
It appears that running just ArmoryQt.py without starting ArmoryDB beforehand just results in it never getting out of the "Preparing databases" stage.
I had that with 33dc929. Otherwise stable. It happened to me in between header scanning and tx scanning, ArmoryLog.txt shows it I think: Log file doesn't exist [yet]
/home/user/BitcoinArmory/armoryengine/Transaction.py:2760: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(ERROR) Traceback (most recent call last):
File "./ArmoryQt.py", line 6691, in method_signal
method()
File "./ArmoryQt.py", line 6741, in completeBlockchainProcessingInitialization
self.setupLedgerViews()
File "./ArmoryQt.py", line 6790, in setupLedgerViews
self.lockboxLedgModel.setLedgerDelegate(TheBDM.bdv().getLedgerDelegateForLockboxes())
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1269, in getLedgerDelegateForLockboxes
def getLedgerDelegateForLockboxes(self): return _CppBlockUtils.BlockDataViewer_getLedgerDelegateForLockboxes(self)
RuntimeError: unexpected return value
Traceback (most recent call last):
File "./ArmoryQt.py", line 6691, in method_signal
method()
File "./ArmoryQt.py", line 6741, in completeBlockchainProcessingInitialization
self.setupLedgerViews()
File "./ArmoryQt.py", line 6790, in setupLedgerViews
self.lockboxLedgModel.setLedgerDelegate(TheBDM.bdv().getLedgerDelegateForLockboxes())
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1269, in getLedgerDelegateForLockboxes
def getLedgerDelegateForLockboxes(self): return _CppBlockUtils.BlockDataViewer_getLedgerDelegateForLockboxes(self)
RuntimeError: unexpected return value
No lockboxes defined atm. Also, all transaction info windows that work (i.e. all except coinbase creation) show " Not in the blockchain yet" for block # (hover over for confirmations works, however)
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 30, 2016, 04:01:33 PM
Give this last push a spin. I'll be away till Sunday evening.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on July 31, 2016, 11:48:22 AM
armorylog.txt: *** Error in `./ArmoryDB': double free or corruption (fasttop): 0x00007ff2f4000920 *** Probably warrants some attention. Happened during txscan (and stopped it getting any further) Still getting (different) problems with ArmoryDb not always getting shut when ArmoryQt is shut. And one case of ArmoryQt not starting ArmoryDb (but ArmoryQt had all the tx details displayed, so I was a bit confused as to why the block count wasn't increasing)
Title: Re: Armory 0.95 testing phase
Post by: goatpig on July 31, 2016, 10:01:18 PM
armorylog.txt: *** Error in `./ArmoryDB': double free or corruption (fasttop): 0x00007ff2f4000920 *** Probably warrants some attention. Happened during txscan (and stopped it getting any further) Last push seems to have fixed the db instabilities. Still some issue left with the client side sometimes hanging. Working on that atm. Still getting (different) problems with ArmoryDb not always getting shut when ArmoryQt is shut.
Happened after I moved the socket code from select to poll, will look into it after everything is stable And one case of ArmoryQt not starting ArmoryDb (but ArmoryQt had all the tx details displayed, so I was a bit confused as to why the block count wasn't increasing)
Sounds like DB crashed at some point after a successful startup.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 01, 2016, 01:48:17 AM
On the latest dev, whenever I start the DB and then start Qt, as soon as Qt is up, the DB segfaults. This is the error: -INFO - 1470015657: (main.cpp:25) Ram usage level: 4
-INFO - 1470015657: (BlockUtils.cpp:1247) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1470015657: (BlockUtils.cpp:1248) lmdb dir: /media/andy/Data/Data/bitcoin/ArmoryData/databases
-INFO - 1470015657: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470015657: (BlockUtils.cpp:1438) Executing: doInitialSyncOnLoad
-INFO - 1470015657: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1470015657: (lmdb_wrapper.cpp:1203) No headers in DB yet!
-INFO - 1470015657: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1470015657: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1470015657: (Blockchain.cpp:232) Organizing chain
-DEBUG - 1470015657: (Blockchain.cpp:232) Organizing chain
-INFO - 1470015657: (BitcoinP2P.cpp:725) Connected to Bitcoin node
0.001042s
-INFO - 1470015657: (BlockUtils.cpp:1549) Enabling zero-conf tracking
-INFO - 1470015756: (BDM_Server.cpp:573) registered bdv: f4f969be1fa8cf1e0807
-INFO - 1470015756: (BDM_supportClasses.cpp:387) Starting address registration process
-ERROR - 1470015756: (lmdb_wrapper.cpp:1462) Headers DB has no block at height: 0
-ERROR - 1470015756: (lmdb_wrapper.cpp:1442) No headers at height 0
Edit: GDB backtrace: #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
#1 0x000000000041f419 in BinaryData::copyFrom (this=0x7fffaf7fda80,
inData=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, sz=80)
at BinaryData.h:195
#2 0x0000000000456092 in BlockHeader::unserialize (this=0x7fffaf7fda80,
ptr=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, size=80)
at BlockObj.cpp:30
#3 0x0000000000456231 in BlockHeader::unserialize (this=0x7fffaf7fda80, str=...) at BlockObj.cpp:46
#4 0x00000000005aebf3 in BlockHeader::BlockHeader (this=0x7fffaf7fda80, str=...) at BlockObj.h:240
#5 0x00000000005a670b in BlockData::deserialize(unsigned char const*, unsigned long, BlockHeader const*, std::function<unsigned int ()>, bool) (this=0x7fffa8000d98,
data=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>,
size=4294967295, blockHeader=0x7fffe4001348, getID=..., checkMerkle=false)
at BlockDataMap.cpp:25
#6 0x0000000000571f5b in BlockchainScanner::<lambda(unsigned int)>::operator()(unsigned int) const
(__closure=0x7fffaf7fdd60, height=0) at BlockchainScanner.cpp:263
#7 0x0000000000572350 in BlockchainScanner::<lambda(std::function<void(const BlockData&)>)>::operator()(std::function<void(const BlockData&)>) const (__closure=0x7fffaf7fdd70, callback=...)
at BlockchainScanner.cpp:294
#8 0x000000000057321a in BlockchainScanner::scanBlockData (this=0x7fffd17f9a10, batch=...,
scrRefSet=...) at BlockchainScanner.cpp:450
#9 0x0000000000570920 in BlockchainScanner::<lambda(std::shared_ptr<BlockDataBatch>)>::operator()(std::shared_ptr<BlockDataBatch>) const (__closure=0x7fffb4000968, batch=...)
at BlockchainScanner.cpp:74
#10 0x0000000000581408 in std::_Bind_simple<BlockchainScanner::scan_nocheck(uint32_t)::<lambda(std::shared_ptr<BlockDataBatch>)>(std::shared_ptr<BlockDataBatch>)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0x7fffb4000958) at /usr/include/c++/5/functional:1531
#11 0x000000000058109a in std::_Bind_simple<BlockchainScanner::scan_nocheck(uint32_t)::<lambda(std::shared_ptr<BlockDataBatch>)>(std::shared_ptr<BlockDataBatch>)>::operator()(void) (
this=0x7fffb4000958) at /usr/include/c++/5/functional:1520
#12 0x0000000000580e38 in std::thread::_Impl<std::_Bind_simple<BlockchainScanner::scan_nocheck(uint32_t)::<lambda(std::shared_ptr<BlockDataBatch>)>(std::shared_ptr<BlockDataBatch>)> >::_M_run(void) (
this=0x7fffb4000940) at /usr/include/c++/5/thread:115
#13 0x00007ffff78f2030 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#14 0x00007ffff7bc26aa in start_thread (arg=0x7fffaf7fe700) at pthread_create.c:333
#15 0x00007ffff705713d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Title: Re: Armory 0.95 testing phase
Post by: mocacinno on August 01, 2016, 07:29:10 AM
on the latest pull, i get the following:
./ArmoryDB --testnet &
Runs without a flaw, and keeps running without a flaw.
./ArmoryQT --testnet
Runs smooth, i claimed some testnet coins, everything seemed to work (so far).
I'll do some more testing when i get home this evening (just had 10 minutes to try this out, but so far it looks promising)!
Keep up the good work :)
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 01, 2016, 11:59:55 AM
On the latest dev, whenever I start the DB and then start Qt, as soon as Qt is up, the DB segfaults.
Delete your db and try again.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 01, 2016, 01:09:23 PM
On the latest dev, whenever I start the DB and then start Qt, as soon as Qt is up, the DB segfaults.
Delete your db and try again. When I delete the databases folder, it doesn't seem able to be creating a new one, instead it tells me the folder cannot be found. I have to create it by hand. Note: I am using a custom datadir and satoshi-datadir. And I'm on mainnet. Edit: I think it is a problem with my custom datadir. It works find on default.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 01, 2016, 01:20:40 PM
On the latest dev, whenever I start the DB and then start Qt, as soon as Qt is up, the DB segfaults.
Delete your db and try again. When I delete the databases folder, it doesn't seem able to be creating a new one, instead it tells me the folder cannot be found. I have to create it by hand. Note: I am using a custom datadir and satoshi-datadir. And I'm on mainnet. Edit: I think it is a problem with my custom datadir. It works find on default. It won't create the folder by default. If you use --datadir, it will append /databases at the end to get the dbdir. If you --dbdir, it's gonna use it as is for the db, but use defaults for the datadir. DB doesn't really need to have access to your actual --datadir (the one with wallet files and settings files). Currently it only uses that location to save its log file. In the future it will need that for its .conf file and some extra stuff. Now that I think about it, it should create the dbdir if it's missing.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 01, 2016, 01:28:14 PM
Now that I think about it, it should create the dbdir if it's missing.
It should definitely do that. So what looks like is happening is that if the databases folder was empty and I had to create it, then it will segfault when Qt starts up.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 01, 2016, 08:19:12 PM
(d4e5687) I'm getting desyncing between client and server before intialising Db completes, armorylog.txt: OError: [Errno 11] Resource temporarily unavailable
close failed in file object destructor:
(ERROR) IOError: [Errno 9] Bad file descriptor
IOError: [Errno 9] Bad file descriptor
** (python:7709): WARNING **: Pixbuf theme: Cannot load pixmap file /usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png: Failed to load image '/usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png': Fatal error in PNG image file: Read Error
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
** (python:7709): WARNING **: Invalid borders specified for theme pixmap:
/usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png,
borders don't fit within the image
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
** (python:7709): WARNING **: Invalid borders specified for theme pixmap:
/usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png,
borders don't fit within the image
Also manifests visually: gui features are missing edges as per the error messages critical and warning errors then begin to repeat in the log file
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 01, 2016, 09:02:56 PM
(d4e5687) I'm getting desyncing between client and server before intialising Db completes, armorylog.txt: OError: [Errno 11] Resource temporarily unavailable
close failed in file object destructor:
(ERROR) IOError: [Errno 9] Bad file descriptor
IOError: [Errno 9] Bad file descriptor
** (python:7709): WARNING **: Pixbuf theme: Cannot load pixmap file /usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png: Failed to load image '/usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png': Fatal error in PNG image file: Read Error
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
** (python:7709): WARNING **: Invalid borders specified for theme pixmap:
/usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png,
borders don't fit within the image
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(python:7709): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
** (python:7709): WARNING **: Invalid borders specified for theme pixmap:
/usr/share/themes/Adwaita/gtk-2.0/Buttons/button-default.png,
borders don't fit within the image
Also manifests visually: gui features are missing edges as per the error messages critical and warning errors then begin to repeat in the log file There is still a bug causing the client to hang under certain conditions. Working on it atm.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 02, 2016, 10:46:25 AM
I've been starting to get syncing issues producing this error too: -INFO - 1470133590: (SocketObject.cpp:338) POLLIN recv return 0 Related to the change in getter method, presumably
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 12:11:08 PM
I've been starting to get syncing issues producing this error too: -INFO - 1470133590: (SocketObject.cpp:338) POLLIN recv return 0 Related to the change in getter method, presumably extra verbose for my debugging purposes.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 12:52:58 PM
Sometimes I get this error: Traceback (most recent call last):
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 1831, in accept
self.saveGeometrySettings()
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 1821, in saveGeometrySettings
self.main.writeSetting('WltPropGeometry', str(self.saveGeometry().toHex()))
File "ArmoryQt.py", line 2857, in writeSetting
self.settings.set(settingName, val)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 3611, in set
self.writeSettingsFile()
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 3690, in writeSettingsFile
f.close()
IOError: [Errno 9] Bad file descriptor
Also, I have had it running since yesterday but it seems like it isn't getting any new blocks even though Core is. And it doesn't update when I restart DB and Qt.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 01:42:46 PM
Sometimes I get this error: Traceback (most recent call last):
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 1831, in accept
self.saveGeometrySettings()
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 1821, in saveGeometrySettings
self.main.writeSetting('WltPropGeometry', str(self.saveGeometry().toHex()))
File "ArmoryQt.py", line 2857, in writeSetting
self.settings.set(settingName, val)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 3611, in set
self.writeSettingsFile()
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 3690, in writeSettingsFile
f.close()
IOError: [Errno 9] Bad file descriptor
Failing to write the settings file, although that's a python only error. Also, I have had it running since yesterday but it seems like it isn't getting any new blocks even though Core is. And it doesn't update when I restart DB and Qt.
Start db individually, does it catch up?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 01:49:08 PM
Start db individually, does it catch up?
No it does not catch up.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 01:53:58 PM
Start db individually, does it catch up?
No it does not catch up. Log file plz
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 02:01:21 PM
Start db individually, does it catch up?
No it does not catch up. Log file plz dbLog.txt latest run:
Log file opened at 1470145631: /media/andy/Data/Data/bitcoin/ArmoryData/dbLog.txt
-INFO - 1470145631: (main.cpp:24) Running on 8 threads
-INFO - 1470145631: (main.cpp:25) Ram usage level: 4
-INFO - 1470145631: (BlockUtils.cpp:1247) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1470145631: (BlockUtils.cpp:1248) lmdb dir: /media/andy/Data/Data/bitcoin/ArmoryData/databases
-INFO - 1470145631: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470145631: (BlockUtils.cpp:1438) Executing: doInitialSyncOnLoad
-INFO - 1470145631: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1470145631: (BitcoinP2P.cpp:725) Connected to Bitcoin node
-INFO - 1470145634: (DatabaseBuilder.cpp:199) Found 422936 headers in db
-INFO - 1470145637: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1470145637: (Blockchain.cpp:232) Organizing chain
-INFO - 1470145637: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.059381s
-INFO - 1470145637: (DatabaseBuilder.cpp:103) scanning new blocks from #422824 to #422823
-INFO - 1470145637: (BlockchainScanner.cpp:51) no history to scan
-INFO - 1470145637: (BlockchainScanner.cpp:802) no SSH to scan
-INFO - 1470145637: (DatabaseBuilder.cpp:153) scanned new blocks in 0.000986s
-INFO - 1470145637: (DatabaseBuilder.cpp:157) init db in 5.32062s
-INFO - 1470145637: (BlockUtils.cpp:1549) Enabling zero-conf tracking
-INFO - 1470145689: (BDM_Server.cpp:573) registered bdv: 893de640c6ee895d17ff
-INFO - 1470145736: (BDM_Server.cpp:604) unregistered bdv: 893de640c6ee895d17ff
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 02:51:18 PM
DB isn't outputting any error. I'm assuming it is running just fine. You saying the clients isn't displaying the proper top block?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 03:00:25 PM
DB isn't outputting any error. I'm assuming it is running just fine. You saying the clients isn't displaying the proper top block?
Yes. I think that these two lines: -INFO - 1470145634: (DatabaseBuilder.cpp:199) Found 422936 headers in db
...
-INFO - 1470145637: (DatabaseBuilder.cpp:103) scanning new blocks from #422824 to #422823 Are a bit concerning. The latest top when I ran it was 423... and it is only scanning from 422823 to 422824.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 03:03:36 PM
Current top is 423333. Check your top block on Core first
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 04:31:11 PM
Current top is 423333. Check your top block on Core first
Top block on core is right. Top block on armory is not.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 04:52:09 PM
Current top is 423333. Check your top block on Core first
Top block on core is right. Top block on armory is not. Time for rebuild & rescan.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 04:55:45 PM
Current top is 423333. Check your top block on Core first
Top block on core is right. Top block on armory is not. Time for rebuild & rescan. It segfaults. I'll get a backtrace in a moment. Well that's not very helpful: (gdb) bt
#0 0x000000000044095e in ?? ()
#1 0x0000000000000000 in ?? ()
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 05:19:47 PM
show me the log output too
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 05:36:44 PM
show me the log output too
-INFO - 1470159382: (main.cpp:24) Running on 8 threads
-INFO - 1470159382: (main.cpp:25) Ram usage level: 4
-INFO - 1470159382: (BlockUtils.cpp:1247) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1470159382: (BlockUtils.cpp:1248) lmdb dir: /media/andy/Data/Data/bitcoin/ArmoryData/databases
-INFO - 1470159382: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470159382: (BlockUtils.cpp:1447) Executing: doInitialSyncOnLoad_Rescan
-INFO - 1470159382: (BitcoinP2P.cpp:725) Connected to Bitcoin node
-INFO - 1470159382: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470159382: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1470159382: (lmdb_wrapper.cpp:1203) No headers in DB yet!
-INFO - 1470159382: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1470159382: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1470159382: (Blockchain.cpp:232) Organizing chain
-INFO - 1470159382: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.000394s
-INFO - 1470159382: (DatabaseBuilder.cpp:103) scanning new blocks from #0 to #0
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 05:43:29 PM
delete the content of your databases folder and try again
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 02, 2016, 05:56:17 PM
delete the content of your databases folder and try again
Then its back to the problem earlier where the DB crashes when Qt starts Let's go to IRC
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 02, 2016, 07:13:29 PM
testing 27e3a36: -ERROR - 1470163647: (BDM_Server.cpp:637) caught isEmpty in Clients maintenance loop
not long after, armorylog.txt hits this: *** Error in `./ArmoryDB': double free or corruption (fasttop): 0x00007f4398000990 ***
-INFO - 1470164078: (SocketObject.cpp:350) POLLIN recv return 0
cpplog.txt: Log file opened at 1470158011: /home/user/.armory/armorycpplog.txt
-ERROR - 1470158308: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470158308: (SocketObject.cpp:139) POLLNVAL in writeToSocket
-ERROR - 1470158308: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470158740: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470158740: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470158740: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470159059: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470159059: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470160347: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470160347: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470160347: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470160367: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470160367: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161382: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161382: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161382: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161382: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161604: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161604: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-ERROR - 1470161604: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
-INFO - 1470164078: (SocketObject.cpp:350) POLLIN recv return 0 This was once it went through a stable build/load. Half a dozen blocks came through once the txscan finished before.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 07:17:30 PM
I've seen the same debug statements on my end. Is you DB/GUI stuck or crashed? Shouldn't be.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 02, 2016, 07:27:32 PM
Nope... Gui was functional enough to shut down with the actual gui, and the Db went down gracefully with it.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 02, 2016, 07:36:10 PM
Nope... Gui was functional enough to shut down with the actual gui, and the Db went down gracefully with it.
At least it's one step further to being stable, I'll take solace in that.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 03, 2016, 12:43:28 AM
Qt started spamming this -ERROR - 1470184862: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
Then it hung with this -ERROR - 1470184862: (SocketObject.cpp:139) POLLNVAL in writeToSocket
And then I had to kill it. The db had this error message -ERROR - 1470184739: (BDM_Server.cpp:637) caught isEmpty in Clients maintenance loop
Also, trying to view any transaction that I received gets me Traceback (most recent call last):
File "ArmoryQt.py", line 3626, in dblClickLedger
self.showLedgerTx()
File "ArmoryQt.py", line 3649, in showLedgerTx
DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5667, in __init__
self.data = extractTxInfo(pytx, txtime)
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError
I think some transactions didn't make it into the db.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 03, 2016, 01:03:27 AM
Qt started spamming this -ERROR - 1470184862: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
Then it hung with this -ERROR - 1470184862: (SocketObject.cpp:139) POLLNVAL in writeToSocket
And then I had to kill it. I'm working on this one. The db had this error message -ERROR - 1470184739: (BDM_Server.cpp:637) caught isEmpty in Clients maintenance loop
This is a debug statement, the error isn't benign. Also, trying to view any transaction that I received gets me Traceback (most recent call last):
File "ArmoryQt.py", line 3626, in dblClickLedger
self.showLedgerTx()
File "ArmoryQt.py", line 3649, in showLedgerTx
DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5667, in __init__
self.data = extractTxInfo(pytx, txtime)
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError
I think some transactions didn't make it into the db. I'm aware of this, will look at it after I stabilize the client.
Title: Re: Armory 0.95 testing phase
Post by: johnlu on August 08, 2016, 04:08:01 PM
There are still a few convenience features I haven't implemented yet, albeit they should be done quickly, notably:
...
- a fee per byte feature in spend dialogs with tx size projections.
Yay! I've been waiting for this feature. Great! :-) Stuff that won't be in the scope of this release and when to expect them:
- New wallets: That's for 0.96, with full SegWit support (create and spend from SW transactions).
- HW wallets support: Most likely a point release for 0.96.
- Fee estimates: Expect a point release on top of 0.95 (.1~2)
- Blocks over P2P. 0.97 most likely
- DB to Client encryption and auth. Again, probably 0.97
- Code modularization: most of it for 0.96
- Supernode: 0.98
Where can I read what an Armory Supernode is?
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 08, 2016, 04:45:07 PM
A supernode in the bitcoin space generally refers to a database that tracks all address history on chain. As an example, this is the kind of engine a blockchain explorer service needs to look up arbitrary address history.
Title: Re: Armory 0.95 testing phase
Post by: jl2012 on August 12, 2016, 12:42:33 AM
Do you use compressed or uncompressed key for segwit?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 12, 2016, 12:45:23 AM
Do you use compressed or uncompressed key for segwit?
Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.
Title: Re: Armory 0.95 testing phase
Post by: droark on August 13, 2016, 06:44:45 PM
Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here (https://github.com/goatpig/BitcoinArmory/pull/50). ArmoryDB still segfaults when Armory runs but at least Armory will compile and start. :)
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 13, 2016, 07:31:47 PM
Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here (https://github.com/goatpig/BitcoinArmory/pull/50). ArmoryDB still segfaults when Armory runs but at least Armory will compile and start. :)
It's failing to create sockets on localhost. If you could look into it that would be a great help
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 15, 2016, 09:44:16 PM
Not sure if this was already reported.
I don't see any of my addresses having a balance when I look at the wallet properties. But I can still send (at least fairly sure that I can) Bitcoin. But coin control doesn't work.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 15, 2016, 09:47:21 PM
Not sure if this was already reported.
I don't see any of my addresses having a balance when I look at the wallet properties. But I can still send (at least fairly sure that I can) Bitcoin. But coin control doesn't work.
Haven't ported these features yet. Coming soon.
Title: Re: Armory 0.95 testing phase
Post by: jl2012 on August 17, 2016, 06:19:34 PM
Do you use compressed or uncompressed key for segwit?
Armory uses uncompressed keys. Segwit wallet support has not been implemented yet. To prevent spamming we may want to make uncompressed keys in segwit non-standard or even invalid. It'd be better for you to use compressed key as it's cheaper anyway
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 17, 2016, 06:22:20 PM
Do you use compressed or uncompressed key for segwit?
Armory uses uncompressed keys. Segwit wallet support has not been implemented yet. To prevent spamming we may want to make uncompressed keys in segwit non-standard or even invalid. It'd be better for you to use compressed key as it's cheaper anyway AFAIK compressed keys will be used in the new wallet format that goatpig will be making. The version with segwit wallet capabilities will have that new wallet.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 17, 2016, 06:44:13 PM
It'd be better for you to use compressed key as it's cheaper anyway
That goes without saying in new wallets. The current wallet format only uses uncompressed keys however. It's an age old, stable format that has proved itself, so I will develop the new format from scratch and leave the current one untouched. The difficulty will be around how to operate legacy wallets imported into the new format with regard to address chains and old backups.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 18, 2016, 06:21:33 PM
Getting the following with 69577e5: (ERROR) BDM.py:184 - DB error: DB version mismatch. Use another dbdir! ...with the accompanying dialog box ("Press OK to quit Armory" etc). Doesn't matter which directory Armory is pointed at, or if there's an absence of ./databases directory.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 18, 2016, 08:02:13 PM
Getting the following with 69577e5: (ERROR) BDM.py:184 - DB error: DB version mismatch. Use another dbdir! ...with the accompanying dialog box ("Press OK to quit Armory" etc). Doesn't matter which directory Armory is pointed at, or if there's an absence of ./databases directory. Changed some formatting and bumped the internal version, use a fresh DB.
Title: Re: Armory 0.95 testing phase
Post by: droark on August 18, 2016, 11:37:38 PM
Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here (https://github.com/goatpig/BitcoinArmory/pull/50). ArmoryDB still segfaults when Armory runs but at least Armory will compile and start. :)
It's failing to create sockets on localhost. If you could look into it that would be a great help Okay. Just looked at the code. Haven't activated debug mode yet but I'd imagine the crash is in the FCGI code, which appears to be pretty ancient. It's not maintained and hasn't been updated in years. I'm not even sure it ever supported OS X. (It was developed before OS X existed and, AFAIK, there was no attempt to port the code.) I'm not entirely offhand sure how to proceed. I don't have a lot of free time to look into this, and if the problem is with the FCGI codebase, who knows how long it'd take to resolve everything. If somebody wants to help, I'd appreciate it. :) EDIT: Derp. Was going off what goatpig said and assumed it was a socket thing. I don't think it is now. Have a core dump and am trying to decipher everything. It won't tell me which thread crashed, unfortunately. EDIT 2: Okay. Dropped the blockfile reading code down to a single thread. Looks like the code doesn't like my copy of testnet's blk00050.dat. Here's the trace for what I believe is the offender. (Unfortunately, LLDB doesn't seem to like to explicitly state which thread crashed. Grrr.) thread #4: tid = 0x0003, 0x000000010039d93f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator<unsigned char>::construct<unsigned char, unsigned char const&>(this=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 16 at memory:1731, stop reason = signal SIGSTOP
frame #0: 0x000000010039d93f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator<unsigned char>::construct<unsigned char, unsigned char const&>(this=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 16 at memory:1731
frame #1: 0x000000010039d92f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator_traits<std::__1::allocator<unsigned char> >::__construct<unsigned char, unsigned char const&>(__a=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 32 at memory:1647
frame #2: 0x000000010039d90f ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator_traits<std::__1::allocator<unsigned char> >::construct<unsigned char, unsigned char const&>(__a=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 32 at memory:1493
frame #3: 0x000000010039d8ef ArmoryDB`std::__1::enable_if<__is_forward_iterator<unsigned char const*>::value, void>::type std::__1::__split_buffer<unsigned char, std::__1::allocator<unsigned char>&>::__construct_at_end<unsigned char const*>(this=0x00007000001824e0, __first="", __last="") + 159 at __split_buffer:263
frame #4: 0x000000010039af4f ArmoryDB`std::__1::enable_if<(__is_forward_iterator<unsigned char const*>::value) && (is_constructible<unsigned char, std::__1::iterator_traits<unsigned char const*>::reference>::value), std::__1::__wrap_iter<unsigned char*> >::type std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::insert<unsigned char const*>(this=0x0000700000182918 size=4, __position=(item = '\0'), __first="", __last="") + 1519 at vector:1981
frame #5: 0x0000000100399d7b ArmoryDB`BinaryData::append(this=0x0000700000182918, bd2=0x00007000001828e8) + 411 at BinaryData.cpp:45
frame #6: 0x000000010061b334 ArmoryDB`BCTX::getHash(this=0x00007f9eab43c288) const + 276 at BlockDataMap.h:79
frame #7: 0x0000000100651129 ArmoryDB`BCTX::moveHash(this=0x00007f9eab43c288) + 25 at BlockDataMap.h:96
frame #8: 0x0000000100648466 ArmoryDB`BlockData::deserialize(this=0x00007000001838c0, data="\x04", size=3868256, blockHeader=0x0000000000000000, getID=function<unsigned int ()> @ 0x0000700000183aa0, checkMerkle=true)>, bool) + 6390 at BlockDataMap.cpp:98
frame #9: 0x00000001005d5faf ArmoryDB`DatabaseBuilder::addBlocksToDB(this=0x00007f9ea9617918, data="\x04", size=3868256, offset=129075608)::$_3::operator()(unsigned char const*, unsigned long, unsigned long) const + 223 at DatabaseBuilder.cpp:322
frame #10: 0x00000001005d5eb9 ArmoryDB`bool std::__1::__invoke_void_return_wrapper<bool>::__call<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) [inlined] decltype(__f=0x00007f9ea9617918, __args=0x0000700000183c08, __args=0x0000700000183c00, __args=0x0000700000183bf8)::$_3&>(fp)(std::__1::forward<unsigned char const*, unsigned long, unsigned long>(fp0))) std::__1::__invoke<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) + 153 at __functional_base:416
frame #11: 0x00000001005d5e7b ArmoryDB`bool std::__1::__invoke_void_return_wrapper<bool>::__call<DatabaseBuilder::addBlocksToDB(__args=0x00007f9ea9617918, __args=0x0000700000183c08, __args=0x0000700000183c00, __args=0x0000700000183bf8)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) + 91 at __functional_base:437
frame #12: 0x00000001005d5d59 ArmoryDB`std::__1::__function::__func<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3, std::__1::allocator<DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>)::$_3>, bool (unsigned char const*, unsigned long, unsigned long)>::operator(this=0x00007f9ea9617910, __arg=0x0000700000183c08, __arg=0x0000700000183c00, __arg=0x0000700000183bf8)(unsigned char const*&&, unsigned long&&, unsigned long&&) + 89 at functional:1437
frame #13: 0x00000001005db97f ArmoryDB`std::__1::function<bool (unsigned char const*, unsigned long, unsigned long)>::operator(this=0x00007000001849a0, __arg="\x04", __arg=3868256, __arg=129075608)(unsigned char const*, unsigned long, unsigned long) const + 175 at functional:1817
frame #14: 0x00000001005d0296 ArmoryDB`DatabaseBuilder::parseBlockFile(this=0x00007f9eab405e80, fileMap="\x04", fileSize=132943864, startOffset=0, callback=function<bool (const unsigned char *, unsigned long, unsigned long)> @ 0x00007000001849a0)>) + 2998 at DatabaseBuilder.cpp:443
frame #15: 0x00000001005ce94e ArmoryDB`DatabaseBuilder::addBlocksToDB(this=0x00007f9eab405e80, bdl=0x0000700000185420, fileID=50, startOffset=0, bo=std::__1::shared_ptr<BlockOffset>::element_type @ 0x00007f9eab4058c8 strong=3 weak=1) + 638 at DatabaseBuilder.cpp:343
frame #16: 0x00000001005ce47b ArmoryDB`DatabaseBuilder::updateBlocksInDB(this=0x0000700000184e48, fileID=50, startOffset=0, bo=std::__1::shared_ptr<BlockOffset>::element_type @ 0x00007f9eab4058c8 strong=3 weak=1, verbose=true)> const&, bool, bool)::$_2::operator()(unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>, bool) const + 283 at DatabaseBuilder.cpp:227
frame #17: 0x00000001005cc758 ArmoryDB`DatabaseBuilder::updateBlocksInDB(this=0x00007f9eab405e80, progress=0x00007f9eab405eb0, verbose=true, initialLoad=true)> const&, bool, bool) + 3384 at DatabaseBuilder.cpp:268
frame #18: 0x00000001005c8ffa ArmoryDB`DatabaseBuilder::init(this=0x00007f9eab405e80) + 1370 at DatabaseBuilder.cpp:50
frame #19: 0x00000001003fe976 ArmoryDB`BlockDataManager::loadDiskState(this=0x00007f9eab404310, progress=0x0000700000186c60, forceRescan=false)> const&, bool) + 1126 at BlockUtils.cpp:1553
frame #20: 0x00000001003fe4e2 ArmoryDB`BlockDataManager::doInitialSyncOnLoad(this=0x00007f9eab404310, progress=0x0000700000186c60)> const&) + 274 at BlockUtils.cpp:1510
frame #21: 0x00000001004c36b7 ArmoryDB`BlockDataManagerThread::run(this=0x00007fff5f87b788) + 951 at BDM_mainthread.cpp:161
frame #22: 0x00000001004c325d ArmoryDB`BlockDataManagerThread::thrun(_self=0x00007fff5f87b788) + 29 at BDM_mainthread.cpp:261
frame #23: 0x00000001004cef6d ArmoryDB`void* std::__1::__thread_proxy<std::__1::tuple<void* (*)(void*), BlockDataManagerThread*> >(void*) [inlined] decltype(__f=0x00007f9eab600330, __args=0x00007f9eab600338)(void*)>(fp)(std::__1::forward<BlockDataManagerThread*>(fp0))) std::__1::__invoke<void* (*)(void*), BlockDataManagerThread*>(void* (*&&)(void*), BlockDataManagerThread*&&) + 24 at __functional_base:416
frame #24: 0x00000001004cef55 ArmoryDB`void* std::__1::__thread_proxy<std::__1::tuple<void* (*)(void*), BlockDataManagerThread*> >(void*) [inlined] void std::__1::__thread_execute<void* (*)(void*), BlockDataManagerThread*, 1ul>(__t=0x00007f9eab600330)(void*), BlockDataManagerThread*>&, std::__1::__tuple_indices<1ul>) + 40 at thread:337
frame #25: 0x00000001004cef2d ArmoryDB`void* std::__1::__thread_proxy<std::__1::tuple<void* (*)(void*), BlockDataManagerThread*> >(__vp=0x00007f9eab600330) + 365 at thread:347
frame #26: 0x00007fff98ad699d libsystem_pthread.dylib`_pthread_body + 131
frame #27: 0x00007fff98ad691a libsystem_pthread.dylib`_pthread_start + 168
frame #28: 0x00007fff98ad4351 libsystem_pthread.dylib`thread_start + 13
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 19, 2016, 02:09:52 PM
Does it always fail at the exact same spot?
Title: Re: Armory 0.95 testing phase
Post by: droark on August 19, 2016, 05:16:12 PM
Does it always fail at the exact same spot?
Yes. I've run it three times. It appears to fail in the exact same spot. -INFO - 1471593104: (DatabaseBuilder.cpp:232) parsed block file #49
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3870106bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3433982bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3342432bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3868824bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 927851bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 645525bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 1047951bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3619855bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3862069bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3863112bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876516bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876290bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876291bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 2067742bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 113849bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 1282bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 275530bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 308762bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 171058bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 2562966bytes
-INFO - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 128376bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3291330bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3295429bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3333425bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3768617bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876436bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3857598bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3628980bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868328bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3869601bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868498bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868406bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876397bytes
-INFO - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
Segmentation fault: 11 (core dumped)
Trace looks the same as the trace I posted previously. Same parameters going into deserialize() and the other function calls. As a side note, once it hits blk00047.dat, the "Found next block after skipped Xbytes" message comes up a lot. It only comes up once before hitting that file. Don't know if that matters but I thought I'd bring it up.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 19, 2016, 08:09:13 PM
As a side note, once it hits blk00047.dat, the "Found next block after skipped Xbytes" message comes up a lot. It only comes up once before hitting that file. Don't know if that matters but I thought I'd bring it up.
It's throwing while it tries to deser the block here: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/DatabaseBuilder.cpp#L314 This is mostly the same code as 0.94. Do you get the same error with the same blockchain data with 0.94?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 19, 2016, 10:03:59 PM
Hmm. Latest build of dev. I don't see any of my transactions now and no balance. The dashboard tab says I am online but the right hand corner says offline.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 19, 2016, 10:30:57 PM
Hmm. Latest build of dev. I don't see any of my transactions now and no balance. The dashboard tab says I am online but the right hand corner says offline.
I'm aware of this. Dev is going to be in limbo for the weekend while I work on some lower level stability issues.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 19, 2016, 11:08:35 PM
I'm experiencing issues with latest Dev also, Db reaches tx scanning and gets stuck. No crash, just wheel-spinning. 2/2 scans produced the same result (at different block heights)
Title: Re: Armory 0.95 testing phase
Post by: droark on August 20, 2016, 12:59:28 AM
This is mostly the same code as 0.94. Do you get the same error with the same blockchain data with 0.94?
No, although it does seem like things slow down quite a bit when reading from the later files. (Fresh DB but everything's multithreaded.) There's definitely something present that Armory doesn't like, although 0.94.1 doesn't crash. With Armory, it takes me ~22 min. to get the testnet DB built from scratch. It slows down when getting near the end (AFAIK) of the files, then takes a little while for the blockchain to organize. Also, it takes 2-3 min. for Armory 0.94.1 to shut down in testnet mode, with 100% CPU utilization the entire time. Don't know if it's related but it seems plausible. Nothing shows up on the command line while all this is happening.
Title: Re: Armory 0.95 testing phase
Post by: alomar on August 22, 2016, 01:25:24 AM
is Armory compatible with Bitcore from Bitpay?
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 22, 2016, 08:43:07 AM
is Armory compatible with Bitcore from Bitpay?
This should be a thread in it's own right, first off. I'm not sure that Bitcore/Armory has ever been tried. Bitcore is in many ways just a re-implementation of Bitcoin Core as far as I'm aware, but there aren't particularly compelling reasons to use it. Although I've not heard of any recent changes to the development direction that might somehow make it attractive for use with Armory? (and not your own personal convenience).
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 28, 2016, 06:04:17 AM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 28, 2016, 02:46:05 PM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still getting tons of these errors: Traceback (most recent call last):
File "ArmoryQt.py", line 5771, in handleCppNotification
self.updateWalletData()
File "ArmoryQt.py", line 5735, in updateWalletData
self.walletMap[wltid].getAddrDataFromDB()
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(*args, **kwargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 3119, in getAddrDataFromDB
countList = self.cppWallet.getAddrTxnCountsFromDB()
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 2354, in getAddrTxnCountsFromDB
return _CppBlockUtils.BtcWallet_getAddrTxnCountsFromDB(self)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f485abb8cf0> >
and it seems that it is stuck at "Scanning Transaction History 100% 1 second". Edit: It fixed itself. Yay! It seems to work! Edit2: Looking at the list of addresses in a wallet, it looks like any address that has a 0 balance is considered unused even though they have been used in the past. Double clicking on the address shows the transactions, but the adddresses in the list are marked as unused with 0 transactions. Edit3: It doesn't detect new ZC transactions and nothing in the log indicates why.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on August 28, 2016, 02:56:47 PM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still getting tons of these errors: Traceback (most recent call last):
File "ArmoryQt.py", line 5771, in handleCppNotification
self.updateWalletData()
File "ArmoryQt.py", line 5735, in updateWalletData
self.walletMap[wltid].getAddrDataFromDB()
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(*args, **kwargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 3119, in getAddrDataFromDB
countList = self.cppWallet.getAddrTxnCountsFromDB()
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 2354, in getAddrTxnCountsFromDB
return _CppBlockUtils.BtcWallet_getAddrTxnCountsFromDB(self)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f485abb8cf0> >
and it seems that it is stuck at "Scanning Transaction History 100% 1 second". Experiencing both issues, but I find the latter issue is just lengthy time without any progress feedback for the user completing the last step of the tx scan ("resolving tx hashes"). I appreciate that using a progress bar wouldn't work for an indicator... something to demonstrate the inability to estimate to the user might be an idea though (i.e. a striped progress bar that clearly doesn't ever complete, but does cascade at a speed related to how fast the tx-Resolve-Hash step is being called/finished). Otherwise that step could be mistaken for a program crash (potential source of frustration for new users, not to mention a source of common user complaints). Otherwise, seems much better. Coinbase tx details bug fixed. ArmoryDb process still detaches itself from the parent process after Quit (i.e. survives when it should die).
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 28, 2016, 05:07:11 PM
Edit3: It doesn't detect new ZC transactions and nothing in the log indicates why.
Is the ZC eventually mined?
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 28, 2016, 05:08:12 PM
I appreciate that using a progress bar wouldn't work for an indicator... something to demonstrate the inability to estimate to the user might be an idea though (i.e. a striped progress bar that clearly doesn't ever complete, but does cascade at a speed related to how fast the tx-Resolve-Hash step is being called/finished). Otherwise that step could be mistaken for a program crash (potential source of frustration for new users, not to mention a source of common user complaints).
I'll add a progress bar for that stuff at some point. For now just assume this step has to happen before the scan completes.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 28, 2016, 05:10:36 PM
Edit3: It doesn't detect new ZC transactions and nothing in the log indicates why.
Is the ZC eventually mined? Yes. It only shows up after it is confirmed.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 28, 2016, 05:11:40 PM
Edit3: It doesn't detect new ZC transactions and nothing in the log indicates why.
Is the ZC eventually mined? Yes. It only shows up after it is confirmed. Do you experience the detached DB issue too?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 28, 2016, 05:40:40 PM
Edit3: It doesn't detect new ZC transactions and nothing in the log indicates why.
Is the ZC eventually mined? Yes. It only shows up after it is confirmed. Do you experience the detached DB issue too? Don't know, haven't and can't check (away from my machine).
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 29, 2016, 02:56:51 AM
Still getting tons of these errors: Traceback (most recent call last):
File "ArmoryQt.py", line 5771, in handleCppNotification
self.updateWalletData()
File "ArmoryQt.py", line 5735, in updateWalletData
self.walletMap[wltid].getAddrDataFromDB()
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(*args, **kwargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 3119, in getAddrDataFromDB
countList = self.cppWallet.getAddrTxnCountsFromDB()
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 2354, in getAddrTxnCountsFromDB
return _CppBlockUtils.BtcWallet_getAddrTxnCountsFromDB(self)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f485abb8cf0> >
Were you getting those while scanning?
Title: Re: Armory 0.95 testing phase
Post by: droark on August 29, 2016, 03:13:44 AM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still seeing testnet crashes w/ ArmoryDB on OS X. Latest code. Same problem as before.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on August 29, 2016, 03:35:50 AM
Were you getting those while scanning?
I think so.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 29, 2016, 07:48:31 AM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still seeing testnet crashes w/ ArmoryDB on OS X. Latest code. Same problem as before. Can you: 1) upload the incriminated block file 2) try to sync against another copy of the testnet
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 29, 2016, 09:27:25 AM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still getting tons of these errors: Traceback (most recent call last):
File "ArmoryQt.py", line 5771, in handleCppNotification
self.updateWalletData()
File "ArmoryQt.py", line 5735, in updateWalletData
self.walletMap[wltid].getAddrDataFromDB()
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(*args, **kwargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 3119, in getAddrDataFromDB
countList = self.cppWallet.getAddrTxnCountsFromDB()
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 2354, in getAddrTxnCountsFromDB
return _CppBlockUtils.BtcWallet_getAddrTxnCountsFromDB(self)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f485abb8cf0> >
and it seems that it is stuck at "Scanning Transaction History 100% 1 second". ArmoryDb process still detaches itself from the parent process after Quit (i.e. survives when it should die). Both issues should be fixed now. Upgraded coin control to display utxos, give that a spin as well. Will work on ZC and progress bars next.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 30, 2016, 04:22:22 AM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still seeing testnet crashes w/ ArmoryDB on OS X. Latest code. Same problem as before. Can you: 1) upload the incriminated block file 2) try to sync against another copy of the testnet Thanks for the file. Can you build a DB from scratch using --db-type=DB_BARE?
Title: Re: Armory 0.95 testing phase
Post by: droark on August 30, 2016, 04:25:18 AM
I think most of the bugs and instability issues reported here should be fixed now. Testers, please pull dev and try again. DB format changed slightly, please start with a fresh folder.
Still seeing testnet crashes w/ ArmoryDB on OS X. Latest code. Same problem as before. Can you: 1) upload the incriminated block file 2) try to sync against another copy of the testnet Thanks for the file. Can you build a DB from scratch using --db-type=DB_BARE? You're welcome. Still crashes, unfortunately. Just to consolidate all the info, 0.94.1 on OSX doesn't crash, and these files don't crash on Linux at all. (I copied the testnet blockchain to Linux, and it was fine.)
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 30, 2016, 04:36:05 AM
You're welcome. Still crashes, unfortunately. Just to consolidate all the info, 0.94.1 on OSX doesn't crash, and these files don't crash on Linux at all. (I copied the testnet blockchain to Linux, and it was fine.)
Try the unit tests in the gtest folder. Both test binaries should pass valgrind --tool=massif
Title: Re: Armory 0.95 testing phase
Post by: droark on August 30, 2016, 04:33:47 PM
You're welcome. Still crashes, unfortunately. Just to consolidate all the info, 0.94.1 on OSX doesn't crash, and these files don't crash on Linux at all. (I copied the testnet blockchain to Linux, and it was fine.)
Try the unit tests in the gtest folder. Both test binaries should pass valgrind --tool=massif Hmmm. I'm seeing a couple of odd things after running Valgrind a few times. [ RUN ] BlockDir.HeadersFirst
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
[ OK ] BlockDir.HeadersFirst (21467 ms)
These messages pop up consistently at this point. These messages seem to be considered spurious by a lot of valgrind users. They apparently pop up quite a bit when running on OSX, which valgrind is slow to support. (In fact, AFAIK, they still haven't implemented full OSX 10.11 support.) I believe they sometimes come up when valgrind doesn't fully understand system calls. It's hard to say but it might be worth looking at this code anyway. Failed to create map of file. Error Code: 22
Saw this once last night but can't reproduce it now for unknown reasons. I think it happened during the Load3Blocks_ZCchain test but I can't remember. Anyway, I believe 22 = EINVAL on OSX. I've written a small patch that uses strerror() in the future. The patch might be why this only came up once. (See below.) Anyway, for some reason, valgrind tripped up here and caused some Armory error code to be triggered (or maybe valgrind just caught the error?). This is actually code that was put in place 6 months ago (https://bitcointalk.org/index.php?topic=1372471.msg13990532#msg13990532) in order for Armory to compile properly after some other changes. Might be worth looking here too, even though I never see the message when running ArmoryDB. [ RUN ] BlockUtilsBare.Load3Blocks_ZC_Plus3_TestLedgers
==6785==
==6785== Process terminating with default action of signal 10 (SIGBUS)
==6785== Non-existent physical address at address 0x1027D6000
==6785== at 0x101935DA0: _platform_memcmp (in /usr/lib/system/libsystem_platform.dylib)
==6785== by 0x100107213: BinaryDataRef::operator==(BinaryData const&) const (BinaryData.h:891)
==6785== by 0x1000F97DC: BinaryDataRef::operator!=(BinaryData const&) const (BinaryData.h:901)
==6785== by 0x1002E7C46: DatabaseBuilder::parseBlockFile(unsigned char const*, unsigned long, unsigned long, std::__1::function<bool (unsigned char const*, unsigned long, unsigned long)>) (DatabaseBuilder.cpp:381)
==6785== by 0x1002E67BD: DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>) (DatabaseBuilder.cpp:327)
==6785== by 0x1002E62EA: DatabaseBuilder::updateBlocksInDB(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool)::$_2::operator()(unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>, bool) const (DatabaseBuilder.cpp:217)
==6785== by 0x1002E4C06: DatabaseBuilder::updateBlocksInDB(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool) (DatabaseBuilder.cpp:257)
==6785== by 0x1002E8586: DatabaseBuilder::update() (DatabaseBuilder.cpp:473)
==6785== by 0x10013C241: BlockDataManager::readBlkFileUpdate(BlockDataManager::BlkFileUpdateCallbacks const&) (BlockUtils.cpp:1559)
==6785== by 0x1001F160D: BlockDataManagerThread::run()::$_4::operator()() const (BDM_mainthread.cpp:178)
==6785== by 0x1001F0EB2: BlockDataManagerThread::run() (BDM_mainthread.cpp:236)
==6785== by 0x1001F04AC: BlockDataManagerThread::thrun(void*) (BDM_mainthread.cpp:261)
--6785:0:schedule VG_(sema_down): read returned -4
==6785==
Killed: 9
Seeing this consistently after one successful run. The invalid address varies slightly but it's always around this particular value. Definitely not good. [----------] 18 tests from BlockUtilsBare
[ RUN ] BlockUtilsBare.Load5Blocks
[ OK ] BlockUtilsBare.Load5Blocks (30152 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_DamagedBlkFile
[ OK ] BlockUtilsBare.Load5Blocks_DamagedBlkFile (6538 ms)
[ RUN ] BlockUtilsBare.Load4Blocks_Plus2
[ OK ] BlockUtilsBare.Load4Blocks_Plus2 (44924 ms)
[ RUN ] BlockUtilsBare.Load4Blocks_ReloadBDM_ZC_Plus2
[ OK ] BlockUtilsBare.Load4Blocks_ReloadBDM_ZC_Plus2 (82404 ms)
[ RUN ] BlockUtilsBare.Load3Blocks_ZC_Plus3_TestLedgers
[ OK ] BlockUtilsBare.Load3Blocks_ZC_Plus3_TestLedgers (89746 ms)
[ RUN ] BlockUtilsBare.Load3Blocks_ZCchain
[ OK ] BlockUtilsBare.Load3Blocks_ZCchain (11110 ms)
[ RUN ] BlockUtilsBare.Load3Blocks_RBF
[ OK ] BlockUtilsBare.Load3Blocks_RBF (497 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_FullReorg
[ OK ] BlockUtilsBare.Load5Blocks_FullReorg (3000 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_DoubleReorg
[ OK ] BlockUtilsBare.Load5Blocks_DoubleReorg (4670 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_ReloadBDM_Reorg
[ OK ] BlockUtilsBare.Load5Blocks_ReloadBDM_Reorg (19694 ms)
[ RUN ] BlockUtilsBare.CorruptedBlock
[ OK ] BlockUtilsBare.CorruptedBlock (8482 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_RescanOps
[ OK ] BlockUtilsBare.Load5Blocks_RescanOps (136481 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_RescanEmptyDB
[ OK ] BlockUtilsBare.Load5Blocks_RescanEmptyDB (22092 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_RebuildEmptyDB
[ OK ] BlockUtilsBare.Load5Blocks_RebuildEmptyDB (68415 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_SideScan
[ OK ] BlockUtilsBare.Load5Blocks_SideScan (39226 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_GetUtxos
[ OK ] BlockUtilsBare.Load5Blocks_GetUtxos (55087 ms)
[ RUN ] BlockUtilsBare.Load4Blocks_ZC_GetUtxos
[ OK ] BlockUtilsBare.Load4Blocks_ZC_GetUtxos (43231 ms)
[ RUN ] BlockUtilsBare.LedgerSeDer
[ OK ] BlockUtilsBare.LedgerSeDer (20928 ms)
[----------] 18 tests from BlockUtilsBare (686681 ms total)
When the tests do succeed under valgrind, the BlockUtilsBare tests take forever. On their own, they don't take too long.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 30, 2016, 06:56:45 PM
[ RUN ] BlockDir.HeadersFirst
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--6464-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
[ OK ] BlockDir.HeadersFirst (21467 ms)
Never seen these. Sounds like OSX specific, not particularly concerned if they don't result in a segfault. Failed to create map of file. Error Code: 22
Can happen sometimes when the OS doesn't create file handles fast enough. Each test completely wipes the db. On some rare occasions (like a system on full load), lmdb will create the db file and try to access it after the call returns but before the OS actually flushes the file to the system (which is a very rare and unexpected window to hit). Not a concern per se, file creation only takes place with empty db folders. Anyway, for some reason, valgrind tripped up here and caused some Armory error code to be triggered (or maybe valgrind just caught the error?). This is actually code that was put in place 6 months ago (https://bitcointalk.org/index.php?topic=1372471.msg13990532#msg13990532) in order for Armory to compile properly after some other changes. Might be worth looking here too, even though I never see the message when running ArmoryDB. [ RUN ] BlockUtilsBare.Load3Blocks_ZC_Plus3_TestLedgers
==6785==
==6785== Process terminating with default action of signal 10 (SIGBUS)
==6785== Non-existent physical address at address 0x1027D6000
==6785== at 0x101935DA0: _platform_memcmp (in /usr/lib/system/libsystem_platform.dylib)
==6785== by 0x100107213: BinaryDataRef::operator==(BinaryData const&) const (BinaryData.h:891)
==6785== by 0x1000F97DC: BinaryDataRef::operator!=(BinaryData const&) const (BinaryData.h:901)
==6785== by 0x1002E7C46: DatabaseBuilder::parseBlockFile(unsigned char const*, unsigned long, unsigned long, std::__1::function<bool (unsigned char const*, unsigned long, unsigned long)>) (DatabaseBuilder.cpp:381)
==6785== by 0x1002E67BD: DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>) (DatabaseBuilder.cpp:327)
==6785== by 0x1002E62EA: DatabaseBuilder::updateBlocksInDB(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool)::$_2::operator()(unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>, bool) const (DatabaseBuilder.cpp:217)
==6785== by 0x1002E4C06: DatabaseBuilder::updateBlocksInDB(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool) (DatabaseBuilder.cpp:257)
==6785== by 0x1002E8586: DatabaseBuilder::update() (DatabaseBuilder.cpp:473)
==6785== by 0x10013C241: BlockDataManager::readBlkFileUpdate(BlockDataManager::BlkFileUpdateCallbacks const&) (BlockUtils.cpp:1559)
==6785== by 0x1001F160D: BlockDataManagerThread::run()::$_4::operator()() const (BDM_mainthread.cpp:178)
==6785== by 0x1001F0EB2: BlockDataManagerThread::run() (BDM_mainthread.cpp:236)
==6785== by 0x1001F04AC: BlockDataManagerThread::thrun(void*) (BDM_mainthread.cpp:261)
--6785:0:schedule VG_(sema_down): read returned -4
==6785==
Killed: 9
Seeing this consistently after one successful run. The invalid address varies slightly but it's always around this particular value. Definitely not good. Now that's something I can't reproduce on my end. My valgrind tests all pass 100%. Can you try reproducing this on a linux setup too? Definitely worth looking into.
Title: Re: Armory 0.95 testing phase
Post by: droark on August 31, 2016, 01:20:11 AM
Anyway, for some reason, valgrind tripped up here and caused some Armory error code to be triggered (or maybe valgrind just caught the error?). This is actually code that was put in place 6 months ago (https://bitcointalk.org/index.php?topic=1372471.msg13990532#msg13990532) in order for Armory to compile properly after some other changes. Might be worth looking here too, even though I never see the message when running ArmoryDB. [ RUN ] BlockUtilsBare.Load3Blocks_ZC_Plus3_TestLedgers
==6785==
==6785== Process terminating with default action of signal 10 (SIGBUS)
==6785== Non-existent physical address at address 0x1027D6000
==6785== at 0x101935DA0: _platform_memcmp (in /usr/lib/system/libsystem_platform.dylib)
==6785== by 0x100107213: BinaryDataRef::operator==(BinaryData const&) const (BinaryData.h:891)
==6785== by 0x1000F97DC: BinaryDataRef::operator!=(BinaryData const&) const (BinaryData.h:901)
==6785== by 0x1002E7C46: DatabaseBuilder::parseBlockFile(unsigned char const*, unsigned long, unsigned long, std::__1::function<bool (unsigned char const*, unsigned long, unsigned long)>) (DatabaseBuilder.cpp:381)
==6785== by 0x1002E67BD: DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>) (DatabaseBuilder.cpp:327)
==6785== by 0x1002E62EA: DatabaseBuilder::updateBlocksInDB(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool)::$_2::operator()(unsigned short, unsigned long, std::__1::shared_ptr<BlockOffset>, bool) const (DatabaseBuilder.cpp:217)
==6785== by 0x1002E4C06: DatabaseBuilder::updateBlocksInDB(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool) (DatabaseBuilder.cpp:257)
==6785== by 0x1002E8586: DatabaseBuilder::update() (DatabaseBuilder.cpp:473)
==6785== by 0x10013C241: BlockDataManager::readBlkFileUpdate(BlockDataManager::BlkFileUpdateCallbacks const&) (BlockUtils.cpp:1559)
==6785== by 0x1001F160D: BlockDataManagerThread::run()::$_4::operator()() const (BDM_mainthread.cpp:178)
==6785== by 0x1001F0EB2: BlockDataManagerThread::run() (BDM_mainthread.cpp:236)
==6785== by 0x1001F04AC: BlockDataManagerThread::thrun(void*) (BDM_mainthread.cpp:261)
--6785:0:schedule VG_(sema_down): read returned -4
==6785==
Killed: 9
Seeing this consistently after one successful run. The invalid address varies slightly but it's always around this particular value. Definitely not good. Now that's something I can't reproduce on my end. My valgrind tests all pass 100%. Can you try reproducing this on a linux setup too? Definitely worth looking into. Hmmm. I'm seeing something different. After one successful run on Linux (Ubuntu 16.04), I kept getting the "Error Code: 22" error on Load3Blocks_ZC_Plus3_TestLedgers and had to disable it. After that, I did see this once. [ RUN ] BlockUtilsBare.Load3Blocks_ZCchain
==20207==
==20207== Process terminating with default action of signal 7 (SIGBUS)
==20207== Non-existent physical address at address 0x403B000
==20207== at 0x5A5D851: __memcmp_sse4_1 (memcmp-sse4.S:812)
==20207== by 0x88E929: BinaryDataRef::operator==(BinaryData const&) const (BinaryData.h:891)
==20207== by 0x88E982: BinaryDataRef::operator!=(BinaryData const&) const (BinaryData.h:901)
==20207== by 0x9BCB7D: DatabaseBuilder::parseBlockFile(unsigned char const*, unsigned long, unsigned long, std::function<bool (unsigned char const*, unsigned long, unsigned long)>) (DatabaseBuilder.cpp:381)
==20207== by 0x9BC5F1: DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::shared_ptr<BlockOffset>) (DatabaseBuilder.cpp:328)
==20207== by 0x9BB9FB: DatabaseBuilder::updateBlocksInDB(std::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool)::{lambda(unsigned short, unsigned long, std::shared_ptr<BlockOffset>, bool)#1}::operator()(unsigned short, unsigned long, std::shared_ptr<BlockOffset>, bool) const (DatabaseBuilder.cpp:217)
==20207== by 0x9BBEA7: DatabaseBuilder::updateBlocksInDB(std::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool, bool) (DatabaseBuilder.cpp:258)
==20207== by 0x9BD2CD: DatabaseBuilder::update() (DatabaseBuilder.cpp:473)
==20207== by 0x8B97C8: BlockDataManager::readBlkFileUpdate(BlockDataManager::BlkFileUpdateCallbacks const&) (BlockUtils.cpp:1559)
==20207== by 0x92A2F5: BlockDataManagerThread::run()::{lambda()#2}::operator()() const (BDM_mainthread.cpp:178)
==20207== by 0x92AAEF: BlockDataManagerThread::run() (BDM_mainthread.cpp:236)
==20207== by 0x92AFFB: BlockDataManagerThread::thrun(void*) (BDM_mainthread.cpp:261)
==20207==
Killed
Unlike the OSX crash, which is consistent, this one only happens occasionally. Also, I forgot to run ContainerTests. No crashes, at least not yet. First is the normal version, second is the Valgrind version, which is still running after almost an hour. (I'll update it if it finishes anytime soon.) This is on Linux. I'll update if OSX has significant differences. [==========] Running 8 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 8 tests from ContainerTests
[ RUN ] ContainerTests.TransactionalMap
[ OK ] ContainerTests.TransactionalMap (216 ms)
[ RUN ] ContainerTests.PileTest_Sequential
[ OK ] ContainerTests.PileTest_Sequential (508 ms)
[ RUN ] ContainerTests.PileTest_Concurrent
[ OK ] ContainerTests.PileTest_Concurrent (934 ms)
[ RUN ] ContainerTests.StackTest_Sequential
[ OK ] ContainerTests.StackTest_Sequential (718 ms)
[ RUN ] ContainerTests.StackTest_Concurrent
[ OK ] ContainerTests.StackTest_Concurrent (590 ms)
[ RUN ] ContainerTests.BlockingStackTest_Sequential
[ OK ] ContainerTests.BlockingStackTest_Sequential (689 ms)
[ RUN ] ContainerTests.BlockingStackTest_Concurrent
ContainerTests.cpp:576: Failure
Expected: (theStack.count()) != (0), actual: 0 vs 0
[ FAILED ] ContainerTests.BlockingStackTest_Concurrent (1099 ms)
[ RUN ] ContainerTests.TimedStackTest_Concurrent
[ OK ] ContainerTests.TimedStackTest_Concurrent (2850 ms)
[----------] 8 tests from ContainerTests (7604 ms total)
[----------] Global test environment tear-down
[==========] 8 tests from 1 test case ran. (7604 ms total)
[ PASSED ] 7 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] ContainerTests.BlockingStackTest_Concurrent
1 FAILED TEST
==23036== Massif, a heap profiler
==23036== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==23036== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23036== Command: ./ContainerTests
==23036==
[==========] Running 8 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 8 tests from ContainerTests
[ RUN ] ContainerTests.TransactionalMap
[ OK ] ContainerTests.TransactionalMap (9033 ms)
[ RUN ] ContainerTests.PileTest_Sequential
[ OK ] ContainerTests.PileTest_Sequential (6640 ms)
[ RUN ] ContainerTests.PileTest_Concurrent
ContainerTests.cpp:249: Failure
Value of: poptally
Actual: 540229271904773
Expected: pushtally
Which is: 858672733906290
ContainerTests.cpp:250: Failure
Value of: 0
Expected: thePile.count()
Which is: 296875
[ FAILED ] ContainerTests.PileTest_Concurrent (71804 ms)
[ RUN ] ContainerTests.StackTest_Sequential
[ OK ] ContainerTests.StackTest_Sequential (3947 ms)
[ RUN ] ContainerTests.StackTest_Concurrent
ContainerTests.cpp:400: Failure
Value of: poptally
Actual: 809112423041638
Expected: pushtally
Which is: 859016864469035
ContainerTests.cpp:401: Failure
Value of: 0
Expected: theStack.count()
Which is: 46511
[ FAILED ] ContainerTests.StackTest_Concurrent (106924 ms)
[ RUN ] ContainerTests.BlockingStackTest_Sequential
[ OK ] ContainerTests.BlockingStackTest_Sequential (11527 ms)
[ RUN ] ContainerTests.BlockingStackTest_Concurrent
: Interestingly, on OSX, ContainerTests passes every time, yet when running under valgrind, BlockingStackTest_Concurrent seems to get stuck, just like on Linux.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on August 31, 2016, 05:09:50 AM
Hmmm. I'm seeing something different. After one successful run on Linux (Ubuntu 16.04), I kept getting the "Error Code: 22" error on Load3Blocks_ZC_Plus3_TestLedgers and had to disable it. After that, I did see this once.
Clearly there's something off with the comparison function, or it is fed an empty pointer eventually. Is it happening at random in any test or always the same spot? Also, I forgot to run ContainerTests. No crashes, at least not yet. First is the normal version, second is the Valgrind version, which is still running after almost an hour. (I'll update it if it finishes anytime soon.) This is on Linux. I'll update if OSX has significant differences.
All those are benign or false positives, nothing alarming here at least EDIT: Interestingly, on OSX, ContainerTests passes every time, yet when running under valgrind, BlockingStackTest_Concurrent seems to get stuck, just like on Linux.
Yep, expected, forgot to rework the BlockingStack clean up method, which will end up hanging on heavy loads. It's only used when shutting down the DB, so I'm not in a hurry to fix it yet.
Title: Re: Armory 0.95 testing phase
Post by: droark on August 31, 2016, 06:03:10 AM
Hmmm. I'm seeing something different. After one successful run on Linux (Ubuntu 16.04), I kept getting the "Error Code: 22" error on Load3Blocks_ZC_Plus3_TestLedgers and had to disable it. After that, I did see this once.
Clearly there's something off with the comparison function, or it is fed an empty pointer eventually. Is it happening at random in any test or always the same spot? The error code? It happens consistently on Linux when valgrind is used. [----------] 18 tests from BlockUtilsBare
[ RUN ] BlockUtilsBare.Load5Blocks
[ OK ] BlockUtilsBare.Load5Blocks (1398 ms)
[ RUN ] BlockUtilsBare.Load5Blocks_DamagedBlkFile
[ OK ] BlockUtilsBare.Load5Blocks_DamagedBlkFile (7102 ms)
[ RUN ] BlockUtilsBare.Load4Blocks_Plus2
[ OK ] BlockUtilsBare.Load4Blocks_Plus2 (1251 ms)
[ RUN ] BlockUtilsBare.Load4Blocks_ReloadBDM_ZC_Plus2
[ OK ] BlockUtilsBare.Load4Blocks_ReloadBDM_ZC_Plus2 (10502 ms)
[ RUN ] BlockUtilsBare.Load3Blocks_ZC_Plus3_TestLedgers
Failed to create map of file. Error Code: 22 (Invalid argument)
On its own, the tests pass. Sorry. Didn't make that clear the first time.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 02, 2016, 12:55:47 PM
Added ZC notifications. It will give you an specific error message on transactions that failed to broadcast.
Fixed some progress bars, added one for the tx resolution. It's still a bit whacky, mainly the ETA, but the progress reporting is decent.
Added fee per byte option to the send dialog.
Also added a bunch of tentative fixes for the other issues listed here (that I sadly can't reproduce T_T). Please test away.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 02, 2016, 11:52:37 PM
Looking good so far. Previous issues seem to have been dealt with, other than the incomplete list of addresses in Wallet Properties (coin control consistently gets the list of in-use addresses correct, however). Input-fine coin control seems good (maybe using tree layout to expand and collapse the inputs pertaining to a given address would make long lists of inputs more manageable). Satoshi/byte seems to work Ok. Progress bar overhaul works well (functionally and visually). Provokes the same Gtk "object drawn out of bounds" errors we've seen in the past, so if it could be fixed then, presumably a new fix exists in this instance (it's never been more than a concerning looking warning in the logs anyhow).
Title: Re: Armory 0.95 testing phase
Post by: achow101 on September 03, 2016, 05:14:27 AM
This is strange. If I use the shortcut I made to launch Armory, it doesn't work. This is the error from the log: 2016-09-03 01:02 (INFO) -- ArmoryUtils.py:639 - Executing popen: ['./ArmoryDB', '--db-type="DB_FULL"', '--spawnId="5uWPvi3P2wvYyo2xNdpeWKU4spxWvHuDRuCJ9gfxevYd"', '--satoshi-datadir="/media/andy/Data/Programs/Bitcoin/data/blocks"', '--dbdir="/media/andy/Data/Data/bitcoin/ArmoryData/databases"']
2016-09-03 01:02 (ERROR) -- Traceback (most recent call last):
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6631, in method_signal
method()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6668, in completeBlockchainProcessingInitialization
gotDB = self.startArmoryDBIfNecessary()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 2198, in startArmoryDBIfNecessary
spawnId = TheSDM.spawnDB(TheBDM.armoryDBDir)
File "/home/andy/bitcoin/BitcoinArmory/SDM.py", line 490, in spawnDB
launchProcess(pargs, **kargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 642, in launchProcess
return Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, *args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
However if I run the same command from the terminal, I have no problems whatsoever. I am running Ubuntu 16.04. This is probably an issue with my system, but I think it is something to note.
Title: Re: Armory 0.95 testing phase
Post by: droark on September 03, 2016, 06:48:13 PM
ArmoryDB crash still happening on OSX, even with the new code. Will double check to see if it's in the same location but I'd imagine this is the case.
Title: Re: Armory 0.95 testing phase
Post by: josephbisch on September 03, 2016, 08:48:34 PM
This is strange. If I use the shortcut I made to launch Armory, it doesn't work. This is the error from the log: 2016-09-03 01:02 (INFO) -- ArmoryUtils.py:639 - Executing popen: ['./ArmoryDB', '--db-type="DB_FULL"', '--spawnId="5uWPvi3P2wvYyo2xNdpeWKU4spxWvHuDRuCJ9gfxevYd"', '--satoshi-datadir="/media/andy/Data/Programs/Bitcoin/data/blocks"', '--dbdir="/media/andy/Data/Data/bitcoin/ArmoryData/databases"']
2016-09-03 01:02 (ERROR) -- Traceback (most recent call last):
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6631, in method_signal
method()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6668, in completeBlockchainProcessingInitialization
gotDB = self.startArmoryDBIfNecessary()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 2198, in startArmoryDBIfNecessary
spawnId = TheSDM.spawnDB(TheBDM.armoryDBDir)
File "/home/andy/bitcoin/BitcoinArmory/SDM.py", line 490, in spawnDB
launchProcess(pargs, **kargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 642, in launchProcess
return Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, *args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
However if I run the same command from the terminal, I have no problems whatsoever. I am running Ubuntu 16.04. This is probably an issue with my system, but I think it is something to note. Armory is trying to open ArmoryDB as a relative path. That only works if you are have used cd to enter the Armory source tree first. The solution is for Armory to use absolute paths, so people don't need to be in the same directory as Armory to run it.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on September 03, 2016, 09:28:14 PM
This is strange. If I use the shortcut I made to launch Armory, it doesn't work. This is the error from the log: 2016-09-03 01:02 (INFO) -- ArmoryUtils.py:639 - Executing popen: ['./ArmoryDB', '--db-type="DB_FULL"', '--spawnId="5uWPvi3P2wvYyo2xNdpeWKU4spxWvHuDRuCJ9gfxevYd"', '--satoshi-datadir="/media/andy/Data/Programs/Bitcoin/data/blocks"', '--dbdir="/media/andy/Data/Data/bitcoin/ArmoryData/databases"']
2016-09-03 01:02 (ERROR) -- Traceback (most recent call last):
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6631, in method_signal
method()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6668, in completeBlockchainProcessingInitialization
gotDB = self.startArmoryDBIfNecessary()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 2198, in startArmoryDBIfNecessary
spawnId = TheSDM.spawnDB(TheBDM.armoryDBDir)
File "/home/andy/bitcoin/BitcoinArmory/SDM.py", line 490, in spawnDB
launchProcess(pargs, **kargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 642, in launchProcess
return Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, *args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
However if I run the same command from the terminal, I have no problems whatsoever. I am running Ubuntu 16.04. This is probably an issue with my system, but I think it is something to note. Armory is trying to open ArmoryDB as a relative path. That only works if you are have used cd to enter the Armory source tree first. The solution is for Armory to use absolute paths, so people don't need to be in the same directory as Armory to run it. So this update breaks shortcuts right now. That is a bit of an issue.
Title: Re: Armory 0.95 testing phase
Post by: josephbisch on September 03, 2016, 09:45:54 PM
This is strange. If I use the shortcut I made to launch Armory, it doesn't work. This is the error from the log: 2016-09-03 01:02 (INFO) -- ArmoryUtils.py:639 - Executing popen: ['./ArmoryDB', '--db-type="DB_FULL"', '--spawnId="5uWPvi3P2wvYyo2xNdpeWKU4spxWvHuDRuCJ9gfxevYd"', '--satoshi-datadir="/media/andy/Data/Programs/Bitcoin/data/blocks"', '--dbdir="/media/andy/Data/Data/bitcoin/ArmoryData/databases"']
2016-09-03 01:02 (ERROR) -- Traceback (most recent call last):
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6631, in method_signal
method()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 6668, in completeBlockchainProcessingInitialization
gotDB = self.startArmoryDBIfNecessary()
File "/home/andy/bitcoin/BitcoinArmory/ArmoryQt.py", line 2198, in startArmoryDBIfNecessary
spawnId = TheSDM.spawnDB(TheBDM.armoryDBDir)
File "/home/andy/bitcoin/BitcoinArmory/SDM.py", line 490, in spawnDB
launchProcess(pargs, **kargs)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/ArmoryUtils.py", line 642, in launchProcess
return Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, *args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
However if I run the same command from the terminal, I have no problems whatsoever. I am running Ubuntu 16.04. This is probably an issue with my system, but I think it is something to note. Armory is trying to open ArmoryDB as a relative path. That only works if you are have used cd to enter the Armory source tree first. The solution is for Armory to use absolute paths, so people don't need to be in the same directory as Armory to run it. So this update breaks shortcuts right now. That is a bit of an issue. It breaks shortcuts or any use case where someone is trying to run Armory from somewhere other than the Armory source tree. So if they are above a level and try to run "python BitcoinArmory/ArmoryQt.py" that should fail too. A solution is to modify self.dbExecutable in SDM.py to be prepended by the following path. path = os.path.dirname(os.path.abspath(__file__))
self.dbExecutable = os.path.join(path, 'ArmoryDB')
if OS_WINDOWS:
# add .exe to self.dbExecutable
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 04, 2016, 04:30:47 AM
A solution is to modify self.dbExecutable in SDM.py to be prepended by the following path. path = os.path.dirname(os.path.abspath(__file__))
self.dbExecutable = os.path.join(path, 'ArmoryDB')
if OS_WINDOWS:
# add .exe to self.dbExecutable
Done. You should just PR these kind of quick fixes in the future. Provokes the same Gtk "object drawn out of bounds" errors we've seen in the past, so if it could be fixed then, presumably a new fix exists in this instance (it's never been more than a concerning looking warning in the logs anyhow).
I have no idea what the underlying issue actually is, besides that it triggers with older version of PyQt4. I can see it on my Debian7 VM, I don't think I can on Debian 8. What version are you using Qt are you using?
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 04, 2016, 02:52:24 PM
Provokes the same Gtk "object drawn out of bounds" errors we've seen in the past, so if it could be fixed then, presumably a new fix exists in this instance (it's never been more than a concerning looking warning in the logs anyhow).
I have no idea what the underlying issue actually is, besides that it triggers with older version of PyQt4. I can see it on my Debian7 VM, I don't think I can on Debian 8. What version are you using Qt are you using? Version 4.8.6, Debian 8.5. Pretty sure that's the most up to date version in the Debian 8 standard repo.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 06, 2016, 07:28:34 AM
knightdk submitted a PR that makes use of new cookie auth feature from Core 0.12 to setup an RPC socket with the local node in case there is no password setup in bitcoin.conf,
The means Armory can now setup an RPC connection to your node regardless of auto bitcoind management. The bottom line, most evident effect is that it should display your node's calculated minimum acceptable fee per byte when selecting that fee option in the send dialog (as opposed to a plain 0).
This feature will only work if your client has access to a local Core instance. The feature is disabled for remote clients. This is because this feature was done through the path of least resistance, i.e. leveraging the existing RPC code in the Python client.
I will leverage the full benefits of this change as well as make it available to remote clients once I migrate this code to the C++ DB. For now, this is an added bonus to "default" users. On a side note, this should also work on OSX (once I get the db rolling on Macs that is)
Please test this feature thoroughly with both self managed and auto bitcoind. I didn't have time to test it directly yet so I'm hoping you guys can list the issues before hand.
-----
droak: I've managed to reproduce the error code 22 issue with valgrind and the new test. I've split a stress test that doesn't fail on valgrind. Please build the unit tests then run DB1kIterTest with valgrind massif. This shouldn't fail. I'll be looking at error 22 in the mean time.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 06, 2016, 07:29:45 AM
Looking good so far. Previous issues seem to have been dealt with, other than the incomplete list of addresses in Wallet Properties (coin control consistently gets the list of in-use addresses correct, however). Input-fine coin control seems good (maybe using tree layout to expand and collapse the inputs pertaining to a given address would make long lists of inputs more manageable). Satoshi/byte seems to work Ok. Progress bar overhaul works well (functionally and visually). Provokes the same Gtk "object drawn out of bounds" errors we've seen in the past, so if it could be fixed then, presumably a new fix exists in this instance (it's never been more than a concerning looking warning in the logs anyhow).
I was going for the cheapest GUI implementation possible. If someone feels like beefing up the GUI in a PR, by all means be my guest. Otherwise I'll start taking suggestions once the testing builds are out.
Title: Re: Armory 0.95 testing phase
Post by: droark on September 06, 2016, 09:31:28 PM
droak: I've managed to reproduce the error code 22 issue with valgrind and the new test. I've split a stress test that doesn't fail on valgrind. Please build the unit tests then run DB1kIterTest with valgrind massif. This shouldn't fail. I'll be looking at error 22 in the mean time.
Thanks. Had to write a patch (https://github.com/goatpig/BitcoinArmory/pull/86) to get everything to compile. :) Anyway, when running valgrind w/ massif, it's slow as hell. I suspect this one will be running for awhile. I'll report back when it's done. Also, just to confirm, I'll still getting the ArmoryDB crash. Haven't run the other tests yet.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 06, 2016, 10:10:34 PM
droak: I've managed to reproduce the error code 22 issue with valgrind and the new test. I've split a stress test that doesn't fail on valgrind. Please build the unit tests then run DB1kIterTest with valgrind massif. This shouldn't fail. I'll be looking at error 22 in the mean time.
Thanks. Had to write a patch (https://github.com/goatpig/BitcoinArmory/pull/86) to get everything to compile. :) Anyway, when running valgrind w/ massif, it's slow as hell. I suspect this one will be running for awhile. I'll report back when it's done. Also, just to confirm, I'll still getting the ArmoryDB crash. Haven't run the other tests yet. Latest commit has a fix for error code 22.
Title: Re: Armory 0.95 testing phase
Post by: alomar on September 07, 2016, 06:54:07 PM
is Armory compatible with Bitcore from Bitpay?
This should be a thread in it's own right, first off. I'm not sure that Bitcore/Armory has ever been tried. Bitcore is in many ways just a re-implementation of Bitcoin Core as far as I'm aware, but there aren't particularly compelling reasons to use it. Although I've not heard of any recent changes to the development direction that might somehow make it attractive for use with Armory? (and not your own personal convenience). the only reason it would be nice is b/c Trezor works with Bitcore. if Armory did as well, we could have 2 forms of cold storage options with one Bitcore database.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 07, 2016, 07:43:18 PM
Ah, that would be a legitimate convenience. Seems no-one's tried judging by the response, my guess would be it's likely Armory wouldn't be able to read the Bitcore database.
Title: Re: Armory 0.95 testing phase
Post by: alomar on September 07, 2016, 10:15:34 PM
Ah, that would be a legitimate convenience. Seems no-one's tried judging by the response, my guess would be it's likely Armory wouldn't be able to read the Bitcore database.
it could come down to which is easier for goatpig to code; compatibility with Trezor or compatibility with Bitcore.
Title: Re: Armory 0.95 testing phase
Post by: droark on September 08, 2016, 06:03:00 AM
Latest commit has a fix for error code 22.
I'm getting a consistent segfault on BlockDir.HeadersFirst when running on Linux. OS X passes. However, OS X chokes on BlockUtilsBare.FCGIStack and just seems to be stuck, doing nothing for hours.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 08, 2016, 09:24:35 AM
Latest commit has a fix for error code 22.
I'm getting a consistent segfault on BlockDir.HeadersFirst when running on Linux. OS X passes. However, OS X chokes on BlockUtilsBare.FCGIStack and just seems to be stuck, doing nothing for hours. Should be a little better with the current push. Still getting the occasional test hanging on valgrind, will figure that out soon. Ah, that would be a legitimate convenience. Seems no-one's tried judging by the response, my guess would be it's likely Armory wouldn't be able to read the Bitcore database.
it could come down to which is easier for goatpig to code; compatibility with Trezor or compatibility with Bitcore. Once I implement blocks over p2p, the DB will be agnostic to the underlying node. It will be able to talk to any implementation as long as it gets the p2p layer right.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 08, 2016, 10:11:21 AM
Ah, that would be a legitimate convenience. Seems no-one's tried judging by the response, my guess would be it's likely Armory wouldn't be able to read the Bitcore database.
it could come down to which is easier for goatpig to code; compatibility with Trezor or compatibility with Bitcore. Not really. I've seen the way the Bitpay organisation behaves, and don't like them. Not using their software, don't trust them.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 09, 2016, 01:32:40 AM
Latest commit has a fix for error code 22.
I'm getting a consistent segfault on BlockDir.HeadersFirst when running on Linux. OS X passes. However, OS X chokes on BlockUtilsBare.FCGIStack and just seems to be stuck, doing nothing for hours. Slowing zero-ing in on the underlying bug. As soon as I have it isolated it should be easy to correct. I hope to have something tomorrow.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 09, 2016, 08:14:10 AM
achow101 submitted a PR to wrap all user facing strings in the tr() method, which a step required to deploy translations. As with any large Python PR, this has the potential to break a ton of GUI.
The first step before it gets merged is to review the code. I'm inviting my testers to go over the changeset and comment places that are potentially bug prone. Essentially, all this PR should be is a set of exiting GUI strings wrapped in tr().
Once this is reviewed and merged, it will need extensive GUI testing, i.e. click on everything trying to make it break.
You can see the changes here:
https://github.com/goatpig/BitcoinArmory/pull/89/files
Title: Re: Armory 0.95 testing phase
Post by: droark on September 10, 2016, 07:47:28 PM
Latest commit has a fix for error code 22.
I'm getting a consistent segfault on BlockDir.HeadersFirst when running on Linux. OS X passes. However, OS X chokes on BlockUtilsBare.FCGIStack and just seems to be stuck, doing nothing for hours. Slowing zero-ing in on the underlying bug. As soon as I have it isolated it should be easy to correct. I hope to have something tomorrow. Linux does pass CppBlockUtilsTests now but DB1kIterTest gets stuck at 100 iterations. On OSX, CppBlockUtilsTests still gets stuck on FCGIStack but passes DB1kIterTest. This is standalone, with no Valgrind.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 14, 2016, 07:41:21 PM
Moved 0.95 to the testing branch, dev is now for 0.96 development, and won't be stable for a while.
Title: Re: Armory 0.95 testing phase
Post by: Nattygirl on September 14, 2016, 10:09:42 PM
Hi everyone,
So I am busy testing v0.94.99 now and the first script I tried was the BDMbasics_watchBalance.py script, and I am getting this error
Traceback (most recent call last):
File "BDMbasics_watchBalance.py", line 60, in <module>
wlt.registerWallet(isNew=False)
File "../armoryengine/PyBtcWallet.py", line 284, in registerWallet
self.cppWallet = TheBDM.registerWallet(prefixedKeys, self.uniqueIDB58, isNew)
File "../armoryengine/BDM.py", line 116, in inner
return func(*newArgs, **kwargs)
File "../armoryengine/BDM.py", line 246, in registerWallet
return self.bdv().registerWallet(uniqueIDB58, prefixedKeys, isNew)
File "../CppBlockUtils.py", line 1393, in registerWallet
def registerWallet(self, *args): return _CppBlockUtils.BlockDataViewer_registerWallet(self, *args)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f455a913480> >
Anybody got a similar error and solved it?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on September 14, 2016, 11:01:02 PM
Hi everyone,
So I am busy testing v0.94.99 now and the first script I tried was the BDMbasics_watchBalance.py script, and I am getting this error
Traceback (most recent call last):
File "BDMbasics_watchBalance.py", line 60, in <module>
wlt.registerWallet(isNew=False)
File "../armoryengine/PyBtcWallet.py", line 284, in registerWallet
self.cppWallet = TheBDM.registerWallet(prefixedKeys, self.uniqueIDB58, isNew)
File "../armoryengine/BDM.py", line 116, in inner
return func(*newArgs, **kwargs)
File "../armoryengine/BDM.py", line 246, in registerWallet
return self.bdv().registerWallet(uniqueIDB58, prefixedKeys, isNew)
File "../CppBlockUtils.py", line 1393, in registerWallet
def registerWallet(self, *args): return _CppBlockUtils.BlockDataViewer_registerWallet(self, *args)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f455a913480> >
Anybody got a similar error and solved it?
Start ArmoryDB in another shell. Then try again.
Title: Re: Armory 0.95 testing phase
Post by: Nattygirl on September 15, 2016, 01:33:11 PM
Hi
So I executed ArmoryDB, and I still get the same error, I think the problem might come from the _CppBlockUtil.so file,
which I can't view.
I also tried running armoryd.py and it gave me th same problem.
Now I am just stuck.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on September 15, 2016, 03:27:55 PM
Hi
So I executed ArmoryDB, and I still get the same error, I think the problem might come from the _CppBlockUtil.so file,
which I can't view.
I also tried running armoryd.py and it gave me th same problem.
Now I am just stuck.
Try running ArmoryQt first. There's a good chance that Armoryd and the other example scripts don't work anymore due to large architectural changes that just happened.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 27, 2016, 09:34:36 PM
Getting the following with 1456a95: -INFO - 1475011271: (DatabaseBuilder.cpp:49) updated HEADERS db in 4202s
-INFO - 1475011271: (BlockUtils.cpp:1608) Enabling zero-conf tracking
-INFO - 1475011459: (BDM_Server.cpp:826) unregistered bdv: c95295fcd242ae65
-INFO - 1475011847: (BlockchainScanner.cpp:52) no history to scan
-INFO - 1475011934: (BlockchainScanner.cpp:52) no history to scan
-INFO - 1475012073: (BlockchainScanner.cpp:52) no history to scan
Tx scan never happens. CPU usage tanks. No other symptoms.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on September 27, 2016, 09:40:01 PM
Getting the following with 1456a95: -INFO - 1475011271: (DatabaseBuilder.cpp:49) updated HEADERS db in 4202s
-INFO - 1475011271: (BlockUtils.cpp:1608) Enabling zero-conf tracking
-INFO - 1475011459: (BDM_Server.cpp:826) unregistered bdv: c95295fcd242ae65
-INFO - 1475011847: (BlockchainScanner.cpp:52) no history to scan
-INFO - 1475011934: (BlockchainScanner.cpp:52) no history to scan
-INFO - 1475012073: (BlockchainScanner.cpp:52) no history to scan
Tx scan never happens. CPU usage tanks. No other symptoms. Your wallet is unregistering before the scan begins. Are you starting everything in the right order?
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 27, 2016, 10:47:08 PM
Uh, assuming the order is as below. In which case, yes.
1. Bitcoin
2. Armory
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 27, 2016, 10:51:03 PM
Here's a something from ArmoryLog.txt referring to a registerWallet function: 016-09-27 23:25 (INFO) -- ArmoryQt.py:2307 - Setting netmode: 1
2016-09-27 23:25 (ERROR) -- Traceback (most recent call last):
File "./ArmoryQt.py", line 6637, in method_signal
method()
File "./ArmoryQt.py", line 6689, in completeBlockchainProcessingInitialization
self.setupBDV()
File "./ArmoryQt.py", line 6655, in setupBDV
self.walletMap[wltId].registerWallet()
File "/home/user/BitcoinArmory/armoryengine/PyBtcWallet.py", line 284, in registerWallet
self.cppWallet = TheBDM.registerWallet(prefixedKeys, self.uniqueIDB58, isNew)
File "/home/user/BitcoinArmory/armoryengine/BDM.py", line 116, in inner
return func(*newArgs, **kwargs)
File "/home/user/BitcoinArmory/armoryengine/BDM.py", line 246, in registerWallet
return self.bdv().registerWallet(uniqueIDB58, prefixedKeys, isNew)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1417, in registerWallet
def registerWallet(self, *args): return _CppBlockUtils.BlockDataViewer_registerWallet(self, *args)
RuntimeError: data is too large for fcgi packet
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 28, 2016, 07:11:21 AM
Here's a something from ArmoryLog.txt referring to a registerWallet function: 016-09-27 23:25 (INFO) -- ArmoryQt.py:2307 - Setting netmode: 1
2016-09-27 23:25 (ERROR) -- Traceback (most recent call last):
File "./ArmoryQt.py", line 6637, in method_signal
method()
File "./ArmoryQt.py", line 6689, in completeBlockchainProcessingInitialization
self.setupBDV()
File "./ArmoryQt.py", line 6655, in setupBDV
self.walletMap[wltId].registerWallet()
File "/home/user/BitcoinArmory/armoryengine/PyBtcWallet.py", line 284, in registerWallet
self.cppWallet = TheBDM.registerWallet(prefixedKeys, self.uniqueIDB58, isNew)
File "/home/user/BitcoinArmory/armoryengine/BDM.py", line 116, in inner
return func(*newArgs, **kwargs)
File "/home/user/BitcoinArmory/armoryengine/BDM.py", line 246, in registerWallet
return self.bdv().registerWallet(uniqueIDB58, prefixedKeys, isNew)
File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1417, in registerWallet
def registerWallet(self, *args): return _CppBlockUtils.BlockDataViewer_registerWallet(self, *args)
RuntimeError: data is too large for fcgi packet
apparently the one wallet is so large it created a serialized packet over the per packet 64kB limit. Will fix it at some point.
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 28, 2016, 08:12:02 PM
Carlton Banks: your error should be fixed in testing, please pull and lmk.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 29, 2016, 12:35:49 AM
Yep, fixed. Only obvious bug in a quick perusal of the loaded GUI is the same Wallet Properties missing addresses issue (small number of total addresses used are displayed, and total addresses generated has, therefore, the same problem. Generating more isn't the issue, and shouldn't be anyway. Coin Control displays all addresses correctly, and balance displays are unaffected anywhere).
Title: Re: Armory 0.95 testing phase
Post by: goatpig on September 29, 2016, 12:41:48 AM
Yep, fixed. Only obvious bug in a quick perusal of the loaded GUI is the same Wallet Properties missing addresses issue (small number of total addresses used are displayed, and total addresses generated has, therefore, the same problem. Generating more isn't the issue, and shouldn't be anyway. Coin Control displays all addresses correctly, and balance displays are unaffected anywhere).
Do you mind hoping on the IRC channel to talk about that? (#bitcoin-armory on freenode)
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 30, 2016, 03:45:30 PM
Wallet Properties view missing addresses is fixed since yesterday's commits also. All my wallets have their addresses displayed correctly, tested all the filters etc
Title: Re: Armory 0.95 testing phase
Post by: achow101 on September 30, 2016, 03:52:51 PM
Wallet Properties view missing addresses is fixed since yesterday's commits also. All my wallets have their addresses displayed correctly, tested all the filters etc
Make sure that sending and receiving still work. Also, do you see the green highlight for addresses with balances? I don't.
Title: Re: Armory 0.95 testing phase
Post by: Carlton Banks on September 30, 2016, 04:20:51 PM
Green highlight is working for me. (Debian 8.6) Can't yet confirm whether send or receive work.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on October 04, 2016, 09:33:57 PM
New testing builds are available at https://github.com/goatpig/BitcoinArmory/releases/tag/v0.94.99.1-testing. If you download the binaries, make sure that you verify them. The tag and the binaries are both signed with goatpig's offline signing key.
Title: Re: Armory 0.95 testing phase
Post by: Searinox on October 09, 2016, 01:24:18 PM
Is it safe to connect ArmoryDB to a potentially untrusted bitcoind node? Or ArmoryQt to a potentially untrusted ArmoryDB server?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on October 09, 2016, 02:23:23 PM
Is it safe to connect ArmoryDB to a potentially untrusted bitcoind node?
ArmoryDB requires a local Bitcoin node and it must read the block files directly from the disk, so it isn't possible to connect to an untrusted bitcoind, unless you don't trust yourself. Or ArmoryQt to a potentially untrusted ArmoryDB server?
AFAICT, your Bitcoin would still be safe, but not your privacy.
Title: Re: Armory 0.95 testing phase
Post by: Searinox on October 09, 2016, 03:56:35 PM
ArmoryDB requires a local Bitcoin node and it must read the block files directly from the disk, so it isn't possible to connect to an untrusted bitcoind, unless you don't trust yourself.
Aha... question. Does it need access ONLY to the disk where an up to date blockchain exists, or ALSO the bitcoind.exe running instance(remote could still be achieved by pointing the btc folder to a mapped network drive, and forwarding localhost:port to the remote machine). Alternatively, does Armory 0.95 work with a pruned bitcoind node? AFAICT, your Bitcoin would still be safe, but not your privacy.
When you say this, you mean the Qt would poll ADB for info about a specific address, and that gives away what wallet a certain IP address has, right?
Title: Re: Armory 0.95 testing phase
Post by: goatpig on October 09, 2016, 04:11:34 PM
ArmoryDB requires a local Bitcoin node and it must read the block files directly from the disk, so it isn't possible to connect to an untrusted bitcoind, unless you don't trust yourself.
Aha... question. Does it need access ONLY to the disk where an up to date blockchain exists, or ALSO the bitcoind.exe running instance(remote could still be achieved by pointing the btc folder to a mapped network drive, and forwarding localhost:port to the remote machine). The DB reads block data from the path you feed it. It needs a socket to a node (any node) that runs the same network as the chain data on disk (same magic word) to get signals (new blocks, new zc) and broadcast its own tx. The DB gets mempool tx from the node directly (over p2p), however the new block invs over the p2p socket are only used as signals to trigger on disk data checks atm (blocks over p2p is the last stage of that transformation, that's somewhere on the list of todos). So you could run a remote node + blockchain data which you symlink. You will have to build your own DB though, it is hardcoded to only look for nodes on localhost atm. When you say this, you mean the Qt would poll ADB for info about a specific address, and that gives away what wallet a certain IP address has, right?
Upon connection, the client creates a BlockDataViewer instance with the DB, and feeds it all its wallet data (i.e. all addresses in all your wallets). DB calls back client with when necessary (no polling really occurs). An untrusted DB would get to know all your current addresses, and it could serve you bogus data which can be boiled down to DoS and withholding info. It cannot get you to sign anything however. This model is meant to have you connect to trusted DBs. The next step is to encrypt the socket and add authentication. Most likely going the BIP151 way for this.
Title: Re: Armory 0.95 testing phase
Post by: Searinox on October 10, 2016, 08:02:21 PM
ArmoryQt latest build laments about being unable to start the DB if started while the DB is offline, but if ADB is running it handles it closing or restarting just fine. Can AQT be made to not complain if it doesn't find DB running immediately and just wait?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on October 10, 2016, 08:06:57 PM
ArmoryQt latest build laments about being unable to start the DB if started while the DB is offline, but if ADB is running it handles it closing or restarting just fine. Can AQT be made to not complain if it doesn't find DB running immediately and just wait?
If it can't find the DB it will spawn the DB by itself unless the socket it is occupied by something. What error do you get?
Title: Re: Armory 0.95 testing phase
Post by: Searinox on October 11, 2016, 04:20:46 PM
It is a warning, I don't have it up anymore, I will repro it. Also. After running for ~2 days and me doing nothing with it, computer idle, today I came from work to find armoryDB crashed. Armory: latest beta published on the forum, unmanaged bitcoind node. Problem signature:
Problem Event Name: APPCRASH
Application Name: ArmoryDB.exe
Application Version: 0.0.0.0
Application Timestamp: 57f1a01f
Fault Module Name: ArmoryDB.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 57f1a01f
Exception Code: 40000015
Exception Offset: 00000000000f9a8a
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 9071
Additional Information 2: 90719623e2e1d09ab95d0bbb808a8813
Additional Information 3: f515
Additional Information 4: f515d384d99c042243c8e1208441aaea These were the last DB log entries: -INFO - 1476169262: (..\BlockchainScanner.cpp:650) scanned from height #433862 to #433862
-ERROR - 1476169283: (..\BitcoinP2P.cpp:862) caught unkown exception in processDataStackThread
-INFO - 1476169283: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-ERROR - 1476169283: (..\SocketObject.cpp:262) poll() error in readFromSocketThread: 10038
-ERROR - 1476169283: (..\BitcoinP2P.cpp:851) caught SocketError exception in processDataStackThread: poll() error in readFromSocketThread: 10038
-ERROR - 1476169283: (..\SocketObject.cpp:125) poll() error in writeToSocket: 10038
-INFO - 1476202821: (..\BitcoinP2P.cpp:804) Disconnected from Bitcoin node
-INFO - 1476202821: (..\BitcoinP2P.cpp:783) Connected to Bitcoin node OS: Windows 7 SP1 all updates. Setup: Localhost default IP and port bitcoind, DB, and Qt.
Title: Re: Armory 0.95 testing phase
Post by: achow101 on October 11, 2016, 06:21:43 PM
It looks like it received a bad message and just crashed. These crashes are usually hard to reproduce and thus we can't really debug them to fix.
Title: Re: Armory 0.95 testing phase
Post by: Searinox on October 14, 2016, 07:29:06 PM
Earlier today ArmoryDB and Qt were using 20% CPU each in idle. They were hogging the system but Qt's interface at least looked responsive. After restarting Qt the issue disappeared(only restarted Qt, DB went back to normal by itself when I did that). The logs had absolutely nothing in them unusual, just the usual block activity and scan and nothing eyecatching during that time. Is there any way I can debug these?
Title: Re: Armory 0.95 testing phase
Post by: goatpig on October 14, 2016, 07:44:30 PM
Earlier today ArmoryDB and Qt were using 20% CPU each in idle. They were hogging the system but Qt's interface at least looked responsive. After restarting Qt the issue disappeared(only restarted Qt, DB went back to normal by itself when I did that). The logs had absolutely nothing in them unusual, just the usual block activity and scan and nothing eyecatching during that time. Is there any way I can debug these?
Wireshark the data over the local socket, most likely the client is spamming the long poll callback request to the server.
Title: Re: Armory 0.95 testing phase
Post by: Searinox on October 17, 2016, 02:32:01 PM
It happened two more times before I had a chance to get a hold of wireshark.
Title: Re: Armory 0.95 testing phase
Post by: dansmith on October 31, 2016, 08:22:02 PM
Alternatively, does Armory 0.95 work with a pruned bitcoind node?
Came here to ask the same thing. Being a developer myself, are there a lot of changes that have to be implemented in order to make it word with a pruned node?
Title: Re: Armory 0.95 testing phase
Post by: achow101 on October 31, 2016, 08:46:32 PM
Alternatively, does Armory 0.95 work with a pruned bitcoind node?
Came here to ask the same thing. Being a developer myself, are there a lot of changes that have to be implemented in order to make it word with a pruned node? Yes. Lots. Armory currently relies on reading the raw block data from Bitcoin Core and building its own databases that way. That would have to be replaced with an entirely P2P solution which would also probably lead to some optimization issues every time the database needed to be rebuilt.
|