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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

(d4e5687) I'm getting desyncing between client and server before intialising Db completes, armorylog.txt:

Code:

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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: goatpig on August 01, 2016, 08:20:40 AM

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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: achow101 on August 01, 2016, 08:09:23 AM

Quote from: goatpig on August 01, 2016, 06:59:55 AM

Quote from: achow101 on July 31, 2016, 08:48:17 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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: goatpig on August 01, 2016, 06:59:55 AM

Quote from: achow101 on July 31, 2016, 08:48:17 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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: achow101 on July 31, 2016, 08:48:17 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.

mocacinno

legendary

Activity: 3584

Merit: 5243

https://merel.mobi => buy facemasks with BTC/LTC

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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

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:

Code:

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

Code:

#0  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
#1  0x000000000041f419 in BinaryData::copyFrom (this=0x7fffaf7fda80, 
    inData=0xffffffffffffffff , sz=80)
    at BinaryData.h:195
#2  0x0000000000456092 in BlockHeader::unserialize (this=0x7fffaf7fda80, 
    ptr=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, bool) (this=0x7fffa8000d98, 
    data=0xffffffffffffffff , 
    size=4294967295, blockHeader=0x7fffe4001348, getID=..., checkMerkle=false)
    at BlockDataMap.cpp:25
#6  0x0000000000571f5b in BlockchainScanner::::operator()(unsigned int) const
    (__closure=0x7fffaf7fdd60, height=0) at BlockchainScanner.cpp:263
#7  0x0000000000572350 in BlockchainScanner::)>::operator()(std::function) 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::)>::operator()(std::shared_ptr) const (__closure=0x7fffb4000968, batch=...)
    at BlockchainScanner.cpp:74
#10 0x0000000000581408 in std::_Bind_simple)>(std::shared_ptr)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0x7fffb4000958) at /usr/include/c++/5/functional:1531
#11 0x000000000058109a in std::_Bind_simple)>(std::shared_ptr)>::operator()(void) (
    this=0x7fffb4000958) at /usr/include/c++/5/functional:1520
#12 0x0000000000580e38 in std::thread::_Impl)>(std::shared_ptr)> >::_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

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: Carlton Banks on July 31, 2016, 06:48:22 AM

armorylog.txt:

Code:

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

Quote

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

Quote

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

armorylog.txt:

Code:

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

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Give this last push a spin. I'll be away till Sunday evening.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: achow101 on July 30, 2016, 08:07:49 AM

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:

Code:

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)

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

It appears that running just ArmoryQt.py without starting ArmoryDB beforehand just results in it never getting out of the "Preparing databases" stage.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: Carlton Banks on July 30, 2016, 05:02:46 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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: goatpig on July 29, 2016, 06:26:14 PM

Quote

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: goatpig on July 29, 2016, 06:26:14 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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: Carlton Banks on July 29, 2016, 06:04:56 PM

Well, some improvement seems to be evident. Just got through a full Db build, with hiccups.

ArmoryQt quit on the job:

Code:

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

Quote

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

Quote

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)

Quote

Wallet Properties is missing the balances (known issue, right?)

Yes

Quote

Some example armorylog.txt output from my initial nosing around...

A few of these when looking at tx details:

Code:

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:

Code:

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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Well, some improvement seems to be evident. Just got through a full Db build, with hiccups.

ArmoryQt quit on the job:

Code:

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:

Code:

-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



-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



-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



-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



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

Code:

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:

Code:

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

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

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.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

SWIG choking on some new code, fixing it as we speak.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Carlton Banks on July 29, 2016, 01:01:38 PM

Getting build errors with ac2eb68:

Code:

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.

Topic: Armory 0.95 testing phase - page 7. (Read 8478 times)