On master I get a crash and the following from valgrind, which
seems like a libwally bug. Upgrading made it go away.
==45076== Invalid read of size 1
==45076== at 0x1191A1: topo_add_utxos (chaintopology.c:657)
==45076== by 0x11935F: add_tip (chaintopology.c:681)
==45076== by 0x1197E6: have_new_block (chaintopology.c:761)
==45076== by 0x114BB0: process_rawblock (bitcoind.c:480)
==45076== by 0x1140A0: bcli_finished (bitcoind.c:227)
==45076== by 0x1A4CA2: destroy_conn (poll.c:244)
==45076== by 0x1A4CC2: destroy_conn_close_fd (poll.c:250)
==45076== by 0x1B28CD: notify (tal.c:235)
==45076== by 0x1B2DBC: del_tree (tal.c:397)
==45076== by 0x1B3148: tal_free (tal.c:481)
==45076== by 0x1A34C1: io_close (io.c:450)
==45076== by 0x1A53DD: io_loop (poll.c:449)
==45076== Address 0x59fc658 is 4 bytes after a block of size 4 alloc'd
==45076== at 0x483874F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==45076== by 0x1BD3A5: tx_from_bytes (in /home/rusty/lightning-ltest/lightningd/lightningd)
==45076== by 0x1715C3: pull_bitcoin_tx (tx.c:411)
==45076== by 0x16B25A: bitcoin_block_from_hex (block.c:54)
==45076== by 0x114B45: process_rawblock (bitcoind.c:473)
==45076== by 0x1140A0: bcli_finished (bitcoind.c:227)
==45076== by 0x1A4CA2: destroy_conn (poll.c:244)
==45076== by 0x1A4CC2: destroy_conn_close_fd (poll.c:250)
==45076== by 0x1B28CD: notify (tal.c:235)
==45076== by 0x1B2DBC: del_tree (tal.c:397)
==45076== by 0x1B3148: tal_free (tal.c:481)
==45076== by 0x1A34C1: io_close (io.c:450)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* remove libbase58, use base58 from libwally
This removes libbase58 and uses libwally instead.
It allocates and then frees some memory, we may want to
add a function in wally that doesn't or override
wally_operations to use tal.
Signed-off-by: Lawrence Nahum lawrence@greenaddress.it
This fixes block parsing on testnet; specifically, non-standard tx versions.
We hit a type bug in libwally (wallt_get_secp_context()) which I had to
work around for the moment, and the updated libsecp adds an optional hash
function arg to the ECDH function.
Fixes: #2563
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also one less headache for reproducible builds. But unlike
libsodium, this only seems common in Ubuntu.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
jsmn would accept invalid JSON objects. This is bad because it would
set ->size incorrectly: we expect to have at least size * 2 tokens (in
pairs). We want to rely on ->size, but this would create an exploitable
buffer overflow!
Fortunately, this is fixed upstream, so we add a test and upgrade to v1.0.0.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we change an upstream URL, all submodules break. Users would need
to run 'git submodule sync'. Note that the libbacktrace fix was merged
upstream so this is no longer necessary, but it's good for future changes.
Also, stress-testing reveals that git submodule fails locking
'.git/config' when run in paralell. It also segfaults and other
problems.
This is my final attempt to fix submodules; I've wasted far too many
days on obscure problems it creates: I've already lost one copy of my
repo to apparently unfixable submodule preoblems. The next "fix" will
be to simply import the source code so it works properly.
Reported-by: @jsarenik
Fixes: #1543
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Proposed fix for issue #1231 - FreeBSD (tcsh) build problem due
to HOST environment variable.
The variable is used for cross-compilation. The process may be
improved even further in the future. So far this hot fix.
This is how the error before the fix looked like on Arch Linux with
GNU libtool 2.4.6.40-6ca5-dirty:
$ make installcheck
...
make[4]: Entering directory '/home/jasan/lightning/external/libwally-core/src/secp256k1'
/usr/bin/mkdir -p 'testinstall/home/jasan/lightning/external/libwally-core/..'
/bin/sh ./libtool --mode=install /usr/bin/install -c libsecp256k1.la 'testinstall/home/jasan/lightning/external/libwally-core/..'
Usage: /home/jasan/lightning/external/libwally-core/src/secp256k1/libtool [OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool: error: 'testinstall/home/jasan/lightning/external/libwally-core/..' must be an absolute directory name
make[4]: *** [Makefile:910: install-libLTLIBRARIES] Error 1
make[4]: Leaving directory '/home/jasan/lightning/external/libwally-core/src/secp256k1'
make[3]: *** [Makefile:1253: install-exec-recursive] Error 1
make[3]: Leaving directory '/home/jasan/lightning/external/libwally-core/src'
make[2]: *** [Makefile:429: install-exec-recursive] Error 1
make[2]: Leaving directory '/home/jasan/lightning/external/libwally-core'
make[1]: *** [external/Makefile:41: external/libwallycore.a] Error 2
rm external/libwally-core/src/secp256k1/libsecp256k1.la
make[1]: Leaving directory '/home/jasan/lightning'
make: *** [Makefile:430: installcheck] Error 2
Then there was linking error which needed to be fixed by correcting
the idea of installing external libraries to a particular directory.
We can't rely on the existence or not of a header, as Carl's
delete-and-make-submodule change showed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This doesn't cover external libs in general (which *could* be effected by
CFLAGS), but at least all our own objects are rebuilt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You will want to 'make distclean' after this.
I also removed libsecp; we use the one in in libwally anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
