Armory 0.95 testing phase - page 2. | Bitcointalksearch.org

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: Carlton Banks on September 27, 2016, 05:51:03 PM

Here's a something from ArmoryLog.txt referring to a registerWallet function:

Code:

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Here's a something from ArmoryLog.txt referring to a registerWallet function:

Code:

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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Uh, assuming the order is as below. In which case, yes.

1. Bitcoin
2. Armory

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Carlton Banks on September 27, 2016, 04:34:36 PM

Getting the following with 1456a95:

Code:

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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Getting the following with 1456a95:

Code:

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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Nattygirl on September 15, 2016, 08:33:11 AM

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.

Nattygirl

newbie

Activity: 29

Merit: 0

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Nattygirl on September 14, 2016, 05: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
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)
: >

Anybody got a similar error and solved it?

Start ArmoryDB in another shell. Then try again.

Nattygirl

newbie

Activity: 29

Merit: 0

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

Anybody got a similar error and solved it?

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Moved 0.95 to the testing branch, dev is now for 0.96 development, and won't be stable for a while.

droark

sr. member

Activity: 525

Merit: 282

Quote from: goatpig on September 08, 2016, 08:32:40 PM

Quote from: droark on September 08, 2016, 01:03:00 AM

Quote from: goatpig on September 06, 2016, 05:10:34 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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

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

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: droark on September 08, 2016, 01:03:00 AM

Quote from: goatpig on September 06, 2016, 05:10:34 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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: alomar on September 07, 2016, 05:15:34 PM

Quote from: Carlton Banks on September 07, 2016, 02: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.

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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: droark on September 08, 2016, 01:03:00 AM

Quote from: goatpig on September 06, 2016, 05:10:34 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.

Should be a little better with the current push. Still getting the occasional test hanging on valgrind, will figure that out soon.

Quote from: alomar on September 07, 2016, 05:15:34 PM

Quote from: Carlton Banks on September 07, 2016, 02: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.

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.

droark

sr. member

Activity: 525

Merit: 282

Quote from: goatpig on September 06, 2016, 05:10:34 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.

alomar

member

Activity: 178

Merit: 10

Quote from: Carlton Banks on September 07, 2016, 02: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.

it could come down to which is easier for goatpig to code; compatibility with Trezor or compatibility with Bitcore.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

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.

alomar

member

Activity: 178

Merit: 10

Quote from: Carlton Banks on August 22, 2016, 03:43:07 AM

Quote from: alomar on August 21, 2016, 08:25:24 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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: droark on September 06, 2016, 04:31:28 PM

Quote from: goatpig on September 06, 2016, 02:28:34 AM

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

Topic: Armory 0.95 testing phase - page 2. (Read 8508 times)