0.96 preliminary testing - page 6. | Bitcointalksearch.org

goatpig

legendary

Activity: 3794

Merit: 1375

Armory Developer

Quote

Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.

Fixed.

Quote

Should DB being shutting down when Client closes even though I run DB separately?

Won't do it anymore now.

Quote

Test suite is broken. Submitted a PR.

Merged. Also merged the translation PR, have fun with that.

Edit: If your PR adds a feature or fixes something I missed from previous versions, please update the changelog as accordingly as well.

droark

sr. member

Activity: 525

Merit: 282

Test suite is broken. Submitted a PR.

goatpig

legendary

Activity: 3794

Merit: 1375

Armory Developer

Quote from: achow101 on February 14, 2017, 01:17:07 PM

Should DB being shutting down when Client closes even though I run DB separately?

DB now uses a cookie file setup to authorize special commands like shutdown. Any local client can read that cookie file, which the DB creates under any circumstances. I guess I could add some cli magic in there to make it a bit more intuitive.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Should DB being shutting down when Client closes even though I run DB separately?

goatpig

legendary

Activity: 3794

Merit: 1375

Armory Developer

Quote from: Carlton Banks on February 13, 2017, 06:39:16 PM

Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf

It looks for .bitcoin/testnet3/bitcoin.conf in testnet. At any rate, it should work if the RPC is off as well. That's a bug that needs fixing.

Quote

Actually it wasn't set, but I think that is because Armory is looking for a bitcoin.conf in /testnet3 instead of in as I'm pretty sure Core still uses the one in

I did this on purpose. I am aware of the reason why it should use the .conf in the parent bitcoin folder, but it's weird enough that I'd rather not introduce weird edge cases in my own path discovery code.

I will move RPC detection to simply probing the socket soon enough.

Quote

Edit: I have resolved the above issues, it was due to some extra debugging code left in the codebase. Here's a PR for it: https://github.com/goatpig/BitcoinArmory/pull/172. Still hunting down bugs in the send dialog, will continue in more posts instead of editing this one.

Already have a fix for that locally. I'm going through the PRs first then pushing this fix.

Quote

Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.

That has to do with the dashboard snafu, will fix it soon.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Carlton Banks on February 13, 2017, 07:46:54 PM

Makes more sense. Core issue is now more pressing, however.

Quote from: achow101 on February 13, 2017, 07:38:16 PM

No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.

I'm not seeing anything relevant in debug.log. Put simply, Core isn't retaining the most recent ~50 blocks between restarts. The amount of missing blocks varies each restart. Provoked by Core not shutting down cleanly when it was tx scanning the wallet (I'd forgotten to add the -disablewallet argument, was being impatient and so interrrupted the Rescan)

Let's move this part of the discussion to Tech Support.

Back to topic.

I am currently testing send and receiving to and from all three address types on testnet. For some reason, when I receive, it suddenly switches back to "Dashboard Scanning Mode" and it doesn't leave that mode even though DB says scanning has completed. Also, this switch only happened when a new block arrived, but it was not the first block that had arrived with Armory started. Restarting the client fixed the problem.

~~It also seems that I am getting the "missing server option from the conf file" error even though that option is set.~~ Actually it wasn't set, but I think that is because Armory is looking for a bitcoin.conf in /testnet3 instead of in as I'm pretty sure Core still uses the one in

This is the error and backtrace I get from just attempting to start ArmoryDB now:

Code:

Thread 4 "ArmoryDB" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffda81c700 (LWP 7888)]
__GI__IO_fwrite (buf=0x7fffd00018f0, size=281, count=1, fp=0x0) at iofwrite.c:37
37	iofwrite.c: No such file or directory.
(gdb) backtrace
#0  __GI__IO_fwrite (buf=0x7fffd00018f0, size=281, count=1, fp=0x0) at iofwrite.c:37
#1  0x000000000067de93 in HttpSocket::makePacket (this=0xb20bb0, packet=0x7fffda81b2d0, 
    msg=0x7fffd0002e60 "{\"id\": 0, \"jsonrpc\": \"2.0\", \"method\": \"getinfo\", \"params\": []}")
    at StringSockets.cpp:83
#2  0x000000000067e5d2 in HttpSocket::writeAndRead (this=0xb20bb0, 
    msg="{\"id\": 0, \"jsonrpc\": \"2.0\", \"method\": \"getinfo\", \"params\": []}", sockfd=2147483647)
    at StringSockets.cpp:123
#3  0x000000000066d952 in NodeRPC::testConnection (this=0xb20a60) at nodeRPC.cpp:70
#4  0x000000000066d6fc in NodeRPC::setupConnection (this=0xb20a60) at nodeRPC.cpp:51
#5  0x000000000066d81c in NodeRPC::testConnection (this=0xb20a60) at nodeRPC.cpp:60
#6  0x0000000000467302 in BlockDataManager::getNodeStatus (this=0xb0d410) at BlockUtils.cpp:1242
#7  0x00000000004d9dc9 in BlockDataManagerThread::::operator()(void) const (__closure=0x7fffda81bd30)
    at BDM_mainthread.cpp:141
#8  0x00000000004db708 in std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/5/functional:1871
#9  0x000000000043a5e4 in std::function::operator()() const (this=0x7fffda81bd30)
    at /usr/include/c++/5/functional:2267
#10 0x00000000006701d2 in NodeRPC::waitOnChainSync(std::function) (this=0xb20a60, callbck=...)
    at nodeRPC.cpp:277
#11 0x00000000004da6ce in BlockDataManagerThread::run (this=0x7fffffffd970) at BDM_mainthread.cpp:154
#12 0x00000000004db214 in BlockDataManagerThread::thrun (_self=0x7fffffffd970) at BDM_mainthread.cpp:302
#13 0x00000000004e05ba in std::_Bind_simple::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xb218b8) at /usr/include/c++/5/functional:1531
#14 0x00000000004e04c4 in std::_Bind_simple::operator()() (
    this=0xb218b8) at /usr/include/c++/5/functional:1520
#15 0x00000000004e0454 in std::thread::_Impl >::_M_run() (this=0xb218a0) at /usr/include/c++/5/thread:115
#16 0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#17 0x00007ffff7bc16ba in start_thread (arg=0x7fffda81c700) at pthread_create.c:333
#18 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I am getting the same error that Carlton is getting when hitting the send button.

Here is the backtrace from gdb:

Code:

(gdb) backtrace
#0  __GI__IO_fwrite (buf=0x7fff70017d80, size=163, count=1, fp=0x0) at iofwrite.c:37
#1  0x000000000056a57c in HttpSocket::makePacket(char**, char const*) ()
#2  0x000000000056a9a9 in HttpSocket::writeAndRead(std::__cxx11::basic_string, std::allocator > const&, int) ()
#3  0x0000000000562b56 in NodeRPC::getFeeByte(unsigned int) ()
#4  0x000000000051d997 in std::_Function_handler, std::allocator >, std::allocator, std::allocator > > > const&, Arguments&), BDV_Server_Object::buildMethodMap()::{lambda(std::vector, std::allocator >, std::allocator, std::allocator > > > const&, Arguments&)#24}>::_M_invoke(std::_Any_data const&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, Arguments&) ()
#5  0x000000000051bd9f in BDV_Server_Object::executeCommand(std::__cxx11::basic_string, std::allocator > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, Arguments&) ()
#6  0x000000000052a1a1 in Clients::runCommand(std::__cxx11::basic_string, std::allocator > const&) ()
#7  0x000000000052a4c0 in FCGI_Server::processRequest(FCGX_Request*) ()
#8  0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00007ffff7bc16ba in start_thread (arg=0x7fff7f7fe700) at pthread_create.c:333
#10 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

It seems that the issue is related to being unable to connect to the RPC server. I will investigate.

Edit: I have resolved the above issues, it was due to some extra debugging code left in the codebase. Here's a PR for it: https://github.com/goatpig/BitcoinArmory/pull/172. Still hunting down bugs in the send dialog, will continue in more posts instead of editing this one.

Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Makes more sense. Core issue is now more pressing, however.

Quote from: achow101 on February 13, 2017, 07:38:16 PM

No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.

I'm not seeing anything relevant in debug.log. Put simply, Core isn't retaining the most recent ~50 blocks between restarts. The amount of missing blocks varies each restart. Provoked by Core not shutting down cleanly when it was tx scanning the wallet (I'd forgotten to add the -disablewallet argument, was being impatient and so interrrupted the Rescan)

I'm not sure whether reindexing will necessarily fix this, and reindexing is a lot of time to commit to.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Carlton Banks on February 13, 2017, 07:22:24 PM

Shouldn't just running with -server=1 from bash work? It's not.

No, it specifically looks for server=1 in the bitcoin.conf. I mentioned it to goatpig yesterday on IRC but he said for now it will just look for that line the conf file, later it will probably be changed to just listening for a response from the RPC connection, which it does anyways.

Quote from: Carlton Banks on February 13, 2017, 07:22:24 PM

I've screwed up my Bitcoin installation anyway, getting strangely random amount of inability to retain the last ~50 blocks, accompanied by SegFault errors, and long startups. Don't tell me, delete the most recent blk.dat files to force a reindex?

No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Shouldn't just running with -server=1 from bash work? It's not.

I've screwed up my Bitcoin installation anyway, getting strangely random amount of inability to retain the last ~50 blocks, accompanied by SegFault errors, and long startups. Don't tell me, delete the most recent blk.dat files to force a reindex?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Carlton Banks on February 13, 2017, 06:39:16 PM

Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf

The bitcoin.conf requirements have changed. It now requires that you have server=1 set (although that should have already been set to enable the RPC server anyways) and it will check for it. It does not require rpcuser or rpcpassword to be set. In fact, I recommend that you don't set those.

Double check that that option is set in the bitcoin.conf and see if it still fails with it set. I will attempt to test this out on my end as well.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Carlton Banks on February 13, 2017, 05:32:50 PM

Not after it crashes

Code:

-ERROR - 1487006286: (nodeRPC.cpp:162) missing server option in node configuration file

That's the only error, I don't think that's the issue. Launch ArmoryQt.py with gdb? Or just for ArmoryDB?

That's the issue I think. Your node can't connect to the RPC server of Bitcoin Core because it isn't set to have the RPC server enabled (at least that's what it thinks). However the send needs RPC functions for the fee/byte stuff.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Not after it crashes

Code:

-ERROR - 1487006286: (nodeRPC.cpp:162) missing server option in node configuration file

That's the only error, I don't think that's the issue. Launch ArmoryQt.py with gdb? Or just for ArmoryDB?

goatpig

legendary

Activity: 3794

Merit: 1375

Armory Developer

Any error on the db side?

Carlton Banks

legendary

Activity: 3430

Merit: 3080

That's it. Entering Send dialog reliably kills the db. Built with latest Whonix (Debian 8.7 based)

goatpig

legendary

Activity: 3794

Merit: 1375

Armory Developer

Quote from: Carlton Banks on February 13, 2017, 09:35:21 AM

I'm getting alot of these with 5a84857:

Code:

Traceback (most recent call last):
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8386, in wltTableClicked
    self.setAddrBookTxModel(self.selectedWltID)
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8283, in setAddrBookTxModel
    self.addrBookTxModel = SentToAddrBookModel(wltID, self.main)
  File "/home/user/BitcoinArmory/armorymodels.py", line 1337, in __init__
    addressBook = self.wlt.cppWallet.createAddressBook();
  File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1949, in createAddressBook
    def createAddressBook(self): return _CppBlockUtils.WalletContainer_createAddressBook(self)
RuntimeError: can't connect socket

....when using the Send dialog (triggered by either Coin Control button or Choose Address button). Subsequently, other parts of the GUI throw this error too (not necessarily with the same traceback).

Looks like the DB is not running.

goatpig

legendary

Activity: 3794

Merit: 1375

Armory Developer

Quote from: achow101 on February 10, 2017, 09:29:37 AM

I currently have an open PR for translations: https://github.com/goatpig/BitcoinArmory/pull/89. The plan is to have this in for 0.96 so if people could test it and review it, that would be great.

Opened a code review of the PR in Github, please go over it.

Quote

Just submitted a PR to get the OSX build going again. There are two problems that still need to be addressed.

Merged #170, don't know the status on #151

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

Anything else I haven't mentioned is still being reviewed/fixed.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

I'm getting alot of these with 5a84857:

Code:

Traceback (most recent call last):
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8386, in wltTableClicked
    self.setAddrBookTxModel(self.selectedWltID)
  File "/home/user/BitcoinArmory/qtdialogs.py", line 8283, in setAddrBookTxModel
    self.addrBookTxModel = SentToAddrBookModel(wltID, self.main)
  File "/home/user/BitcoinArmory/armorymodels.py", line 1337, in __init__
    addressBook = self.wlt.cppWallet.createAddressBook();
  File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1949, in createAddressBook
    def createAddressBook(self): return _CppBlockUtils.WalletContainer_createAddressBook(self)
RuntimeError: can't connect socket

....when using the Send dialog (triggered by either Coin Control button or Choose Address button). Subsequently, other parts of the GUI throw this error too (not necessarily with the same traceback).

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

In the MultiSigDialogs, the MultiSig addresses are being displayed (and maybe stored?) as P2PKH addresses, not P2SH addresses. This is happening with addresses that were already there, and presumably with addresses that are created.

droark

sr. member

Activity: 525

Merit: 282

Just submitted a PR to get the OSX build going again. There are two problems that still need to be addressed.

- cppForSwig/ScriptRecipient.h is inconsistent. getSize() needs to return size_t or uint64_t. As is, the parent class returns size_t and the children return uint64_t. This causes a build error on OSX.
- There's an ArmoryMac issue in the Python code. I'll sort it out in a separate PR.

In addition, Armory doesn't output CSV spreadsheets. Python errors prevent it from happening. I was working on a patch for it and got pulled into something else. I don't think this has worked for quite awhile. I tried 0.94.1 and it didn't work there either. For various reasons, I do think this is a useful feature, and I would like to see it working again. I'm happy to help get the ball rolling, of course.

Thanks.

Topic: 0.96 preliminary testing - page 6. (Read 6375 times)