0.15.0 introduced a new feeest file format, and support for parsing
old versions was never fully added. We now simply fail to read the
old format, so remove the dead partial-implementation.
We use select in ConnectSocketDirectly, so this check needs to happen before
that.
IsSelectableSocket will not be relevant after upcoming changes to remove select.
This fixes a crash bug when opening the options dialog.
- Check the return value of split() to avoid segmentation faults due to
out of bounds when the user manages to enter invalid proxy settings.
This is reported resonably often.
- Move the default proxy/port to a constant instead of hardcoding magic
values.
- Factor out some common code.
- Revert #11448 because this proves a more robust replacement, it is no
longer necessary and didn't generally solve the issue.
No attempt is made to do full sanity checking on the proxy, so it can
still be rejected by the core with an InitError message.
This should fix a very rare travis failure in zapwallettxes, but
is also more correct, as you can currently race
ReacceptWalletTransactions with stop RPC calls to get bitcoind to
(IMO) eroneously return a non-0 exit code.
This patch adds an option to configure the name and/or directory of the
debug log.
The user can specify either a relative path, in which case the path
is relative to the data directory. They can also specify an absolute
path to put the log anywhere else in the file system.
Add leveldb: prefix to leveldb debug logging lines.
leveldb debug messages come in various scary flavors such as:
2017-11-30 08:26:31 leveldb: Recovering log #26
2017-11-30 08:26:31 leveldb: Level-0 table #28: started
2017-11-30 08:26:31 leveldb: Level-0 table #28: 597 bytes OK
2017-11-30 08:26:31 leveldb: Delete type=0 #26
2017-11-30 08:26:31 leveldb: Delete type=3 #24
so it's reasonably important to mark them as coming from leveldb
internals and not from consensus validation wallet or such.
(this only affects `-debug=leveldb` or `-debug=1` otherwise you won't
see them in the first place)
PR #10286 introduced a few steps which are not robust to early shutdown
in initialization.
Stumbled upon this with #11781, not sure if there are other scenarios
that can trigger it, but it's harden against this in any case.
blockchain.cpp has low unit test coverage. This commit is intended
to start improving its code coverage to reasonable levels. One or more
follow up commits will complete the task that this commit is starting
(though the usefulness of this commit is not dependent upon later
commits).
Note that these tests were not written based upon a specification of how
GetDifficulty *should* work, but rather how it actually *does* work. As
a result, if there are any bugs in the current GetDifficulty
implementation, these unit tests serve to lock them in rather than
expose them.
-- Why has blockchain.cpp been modified if this is a unit testing change?
Since the existing GetDifficulty function relies on a global variable,
chainActive, it was not suitable for unit testing purposes. Both the
existing GetDifficulty function and the unit tests now call through to
a new, more modular version of GetDifficulty that can work on any chain,
not just chainActive.
-- Why does blockchain_tests.cpp directly include blockchain.cpp instead
of blockchain.h?
While the new GetDifficulty function's signature is arguably better than
the old one's, it still isn't great, and doesn't seem to warrant inclusion
as part of the blockchain.h API, especially since only test code is
directly using it. If a better way of exposing the new GetDifficulty
function to unit tests exists, please mention it and the commit will be
updated accordingly.
-- Why is the test fixture named blockchain_difficulty_tests rather than
blockchain_tests?
The Bitcoin Core policy for naming unit test files is to match the the
file under test ("blockchain" becomes "blockchain_tests"). While this
commit complies with that, blockchain.cpp is a massive file, such that
having all of the unit tests in one file will tend towards disorder.
Since there will be a lot more tests added to this file, the intention
is to divide up different types of tests into different test fixtures
within the same file.
ConnectBlock() relies on validation that happens in ContextualCheckBlock() and
ContextualCheckBlockHeader(). This has implications for implementing consensus
changes and handling software upgrade to ensure that nodes upgrading their
software end up enforcing all the consensus rules.
MeshCollider