|
Current top is 423333. Check your top block on Core first
|
|
|
|
|
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?
|
|
|
|
Start db individually, does it catch up?
No it does not catch up. Log file plz |
|
|
|
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? |
|
|
|
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. |
|
|
|
(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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
Give this last push a spin. I'll be away till Sunday evening.
|
|
|
|
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. |
|
|
|
|
It's choking on the path. It either doesn't exist, Armory can't extend it (it needs the /blocks path), or the user spawning Armory lacks the privileges to read its content.
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
SWIG choking on some new code, fixing it as we speak.
|
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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 |
|
|
|
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 |
|
|
|
|
Show Posts
