All other users of read_all(...) check the return value:
```
hsmd/hsm.c: if (!read_all(fd, &secretstuff.hsm_secret, sizeof(secretstuff.hsm_secret)))
test/test_protocol.c: if (!read_all(fd, p, len))
wire/wire_sync.c: if (!read_all(fd, &len, sizeof(len)))
wire/wire_sync.c: if (!read_all(fd, msg, wirelen_to_cpu(len)))
```
CI always runs with TEST_DEBUG=1 which prints logs anyway, and testing
locally should also be done this way, combined with pytest which
captures the logs. No need to duplicate the functionality of pytest.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Since we seem to have some isolation concerns when re-generating the
same HSM secret and re-parsing the blockchain some blocks in the past.
This also alleviates the problem of printing to a logging stream that
has been closed. Previously bitcoind would keep running despite a test
had failed and continue logging to the, now closed, StringIO that
py.test uses when capturing stdout.
The performance impact seems to be 1-3 second per test, not too bad
IMHO for increased test isolation and cleaner logs:
|--------------------+---------------+----------|
| | No_valgrind | Valgrind |
|--------------------+---------------+----------|
| bitcoind per suite | 10 min 24 sec | 46:15.31 |
| bitcoind per test | 11 min 38 sec | 49:21.64 |
|--------------------+---------------+----------|
Signed-off-by: Christian Decker <decker.christian@gmail.com>
I've only seen this under travis, so I can't verify that this fixes it,
but it's certainly a bug which could cause that issue.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our handling of SIGPIPE was incoherent and inconsistent, and we had much
cut & paste between the daemons. They should *ALL* ignore SIGPIPE, and
much of the rest of the boilerplate can be shared, so should be.
Reported-by: @ZmnSCPxjFixes: #528
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
So far we have been generating the tx both in the HSM and in the
caller, and had to rely on them generating exactly the same
transaction. This makes it a lot simpler by fully signing and
serializing the TX on the HSM side and the caller just needs to unpack
and broadcast it.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Removes the need to keep a second transaction around and marking it as
`noleak`, just to make sure that dependencies are not free'd along
with the original tx.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The deserialization of bitcoin transactions in wire/ is rather
annoying in that we first allocate a new bitcoin_tx, then copy it's
contents onto the destination and then still carry the newly allocated
one around due to the tal-tree. This splits `pull_bitcoin_tx` into
two: one part that does the allocation and another one that proceeds
to parse.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The close_info is needed to re-derive the secret key that is supposed
to be used to sign the input spending the output.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is necessary to grad the their_unilateral/to-us outputs since
they aren't being harvested by `onchaind`
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is the scriptpubkey that onchaind spends all funds to, except for
the their_unilateral/to-us case, so we better recognize that address.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is the only case in which we don't respend to a simple keyindex'd
pubkey, so we need to handle this for future spends.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
memcmp((p1)->field, (p2)->field, ...) results in undefined behaviour
if (p1)->field or (p2)->field is NULL. This holds also when
tal_count((p1)->field) * sizeof(*(p1)->field) == 0.
I was examining a test_onchain_timeout failure, and realized that we
were forgetting a peer even though we'd just spent the HTLC_TIMEOUT_TX!
This reveals that we weren't resolving an output when we stole the preimage
from it, like we should.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We always arm the funding_lockin_cb, even if we don't need to. If we
have an short_channel_id already from the db, this was replacing it
and leaking the old one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we panic when we see our root reorg out, even if we're not doing
anything yet, restoring the 100 block margin is the simplest fix.
Unfortunately this means adding a 100-block spacer in the tests, so things
don't get confused.
Fixes: #511
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
practicalswift
William Casarin
Rusty Russell
Christian Decker
ZmnSCPxj