The lockorder potential deadlock detection works by remembering for each
lock A that is acquired while holding another B the pair (A,B), and
triggering a warning when (B,A) already exists in the table.
A and B in the above text are represented by pointers to the CCriticalSection
object that is acquired. This does mean however that we need to clean up the
table entries that refer to any critical section which is destroyed, as it
memory address can potentially be used for another unrelated lock in the future.
Implement this clean up by remembering not only the pairs in forward direction,
but also backward direction. This allows for fast iteration over all pairs that
use a deleted CCriticalSection in either the first or the second position.
The current tests for varint only check that
serialization-deserialization is a roundtrip. That is a useful test, but
it is also good to check for some exact bit patterns, to prevent a code
change that changes the serialization format from going undetected.
As the varint functions are templated, also check with different types.
Before activation, such transactions might not be mined, so don't
allow into the mempool.
- Tests: move get_bip9_status to util.py
- Test relay of version 2 transactions
Github-Pull: #7835
Rebased-From: e4ba9f6b045cb1d8a207da5fdbb3a2
da5fdbb Test relay of version 2 transactions (Suhas Daftuar)
5cb1d8a Tests: move get_bip9_status to util.py (Suhas Daftuar)
e4ba9f6 Version 2 transactions remain non-standard until CSV activates (Suhas Daftuar)
Check the Content-Type header that is returned from the RPC server. Only
if it is `application/json` the data is supposed to be parsed as JSON.
This gives better reporting if the HTTP server happens to return an error that is
not JSON-formatted, which is the case if it happens at a lower level
before JSON-RPC kicks in.
Before: `Unexpected exception caught during testing: No JSON object could be decoded`
After: `JSONRPC error: non-JSON HTTP response with '403 Forbidden' from server`
Now that #7804 fixed the timeout handling, reduce the block timeout from
20 minutes to 10 minutes. 20 minutes is overkill.
Conflicts:
src/main.h
Github-Pull: #7832
Rebased-From: 62b9a557fc
Currently, we're keeping a timeout for each requested block, starting
from when it is requested, with a correction factor for the number of
blocks in the queue.
That's unnecessarily complicated and inaccurate.
As peers process block requests in order, we can make the timeout for each
block start counting only when all previous ones have been received, and
have a correction based on the number of peers, rather than the total number
of blocks.
Conflicts:
src/main.cpp
src/main.h
Self check after the last peer is removed
Github-Pull: #7804
Rebased-From: 2d1d6581ec0e24bbf679
Two-line patch to make it possible to shut down bitcoind cleanly during
the initial ActivateBestChain.
Fixes#6459 (among other complaints).
To reproduce:
- shutdown bitcoind
- copy chainstate
- start bitcoind
- let the chain sync a bit
- shutdown bitcoind
- copy back old chainstate
- start bitcoind
- bitcoind will catch up with all blocks during Init()
(the `boost::this_thread::interruption_point` / `ShutdownRequested()`
dance is ugly, this should be refactored all over bitcoind at some point
when moving from boost::threads to c++11 threads, but it works...)
Github-Pull: #7821
Rebased-From: 07398e8e9d
Currently, we're keeping a timeout for each requested block, starting
from when it is requested, with a correction factor for the number of
blocks in the queue.
That's unnecessarily complicated and inaccurate.
As peers process block requests in order, we can make the timeout for each
block start counting only when all previous ones have been received, and
have a correction based on the number of peers, rather than the total number
of blocks.
Two-line patch to make it possible to shut down bitcoind cleanly during
the initial ActivateBestChain.
Fixes#6459 (among other complaints).
To reproduce:
- shutdown bitcoind
- copy chainstate
- start bitcoind
- let the chain sync a bit
- shutdown bitcoind
- copy back old chainstate
- start bitcoind
- bitcoind will catch up with all blocks during Init()
(the `boost::this_thread::interruption_point` / `ShutdownRequested()`
dance is ugly, this should be refactored all over bitcoind at some point
when moving from boost::threads to c++11 threads, but it works...)
New languages:
- `af` Afrikaans
- `es_AR` Spanish (Argentina)
- `es_CO` Spanish (Colombia)
- `ro` Romanian
- `ta` Tamil
- `uz@Latn` Uzbek in Latin script
