This will never be reliable under high load, without making it unable
to detect real errors. But the test is useful because if we don't
have this test we'll never notice if we break the const-timedness of
our implementation.
So, move the calloc out of the test loop (which seems to make it more
reliable), and then after we've run it, check the 1-minute load
average. Too high, we don't complain about results. It's not
perfect, but it's better.
Running 100 times (-O3) serially gave 100 successes with the following results:
Constant: Within 5% 562-926(832.89+/-73)/1000 times
Non-constant: More than 5% slower 860-990(956.35+/-26)/1000 times
More importantly, if we swap the const and non-const tests, we get
the expected 100 failures:
Non-constant: Within 5% 14-79(41.17+/-14)/1000 times
Constant: More than 5% slower 44-231(111.89+/-33)/1000 times
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Generalize things a bit so OPTIONAL_FEATURE() and COMPULSORY_FEATURE()
work with either odd or even features, then explicitly use OPTIONAL_FEATURE
in our internal feature array.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This removes the WIRE_FINAL_EXPIRY_TOO_SOON which leaked too much info,
and adds the blockheight to WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We seem to be getting intermittant failures, but it's hard
to disgnose. Simplify it by moving all the test logic into
the test itself, and making the plugin dumber. This means we'll
see exactly what the differences are if it fails again.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By not depending on plugins, we can call lightningd before plugins are
built, and not get all options:
diff of command names vs manpage names:
--- /dev/fd/63 2019-08-22 05:06:55.265659216 +0000
+++ /dev/fd/62 2019-08-22 05:06:55.265659216 +0000
@@ -3,6 +3,8 @@
allow-deprecated-apis=
always-use-proxy=
announce-addr=
+autocleaninvoice-cycle=
+autocleaninvoice-expired-by=
autolisten=
bind-addr=
bitcoin-cli=
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
installcheck calls $(MAKE) under the covers, which can race with the
current builds, and we can try installing something which is still
being built:
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
/usr/bin/ld: can not read symbols: File truncated
/usr/bin/ld: .eh_frame/.stab edit: File truncated
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.interp' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.note.ABI-tag' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.note.gnu.build-id' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.gnu.hash' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.dynsym' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.dynstr' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.gnu.version' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.gnu.version_r' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.rela.dyn' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.rela.plt' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.init' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.plt' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.plt.got' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.text' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.fini' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.rodata' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.eh_frame' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.init_array' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.fini_array' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.data.rel.ro' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.dynamic' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.got' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.data' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `xautodata_json_command' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `xautodata_hooks' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `xautodata_type_to_string' not in segment
Makefile:390: recipe for target 'lightningd/lightningd' failed
make[1]: *** [lightningd/lightningd] Error 1
make[1]: Leaving directory '/home/rusty/lightning'
Makefile:553: recipe for target 'installcheck' failed
make: *** [installcheck] Error 2
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
VALGRIND=1, SLOW_MACHINE=0:
Before: 197.74 seconds
After: 135.43 seconds
Note that we now spend about 13 seconds in teardown, could probably
be optimized.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Makefile:424: warning: overriding recipe for target 'clean'
tools/Makefile:12: warning: ignoring old recipe for target 'clean'
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fortunately, again, only happens with EXPERIMENTAL_FEATURES.
If the query causes us not to actually send anything, we won't
get called again. This can validly happen if they only asked for
the node_announcements, for example.
(Found by protocol tests).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
___________________________________________________________________________
/ The most important plugin. Ever. Much thanks to @practicalswift and @jb55 \
\ for their improvements! /
---------------------------------------------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our "are we finished?" logic was wrong: it tested if there are no more
node_announcements, but it's possible that there were no node_announcements
for either end of the channel whose information we sent.
This is actually quite unusual on the real network: looking at mainnet
statis from last May, 4301 of 4337 nodes have node_announcements.
However, with query flags it's much more likely, since they might not
ask for node announcements at all.
(Found by gossip protocol tests)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the normal convention for this type; it makes using converters
a little easier. See next patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In contrib/bootstrap-node.sh line 7:
if type lightning-cli >/dev/null 2>&1; then
^-- SC2039: In POSIX sh, 'type' is undefined.
In contrib/startup_regtest.sh line 41:
type lightning-cli || return
^-- SC2039: In POSIX sh, 'type' is undefined.
In contrib/startup_regtest.sh line 42:
type lightningd || return
^-- SC2039: In POSIX sh, 'type' is undefined.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We currently end up sleeping for 1 second for channeld and gossipd:
better to use a normal blocking waitpid and an alarm to wake us in
case they don't exit.
This speeds up `lightning-cli stop` on my machine from 2.008s to 0.008s:
a 286 times speedup!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Because it required update-mocks, which is a hack which relies on the
format of linker errors (!) I'd prefer to make this --enable-developer
only.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to tell it that the tmp file is an intermediate, so doesn't need
remaking if it doesn't exist.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our TLV serializer relies on TLV outputs to be ordered by type
number. Prior to this commit we relied on 1) the ordering in the
RFC to be correct and 2) users to be using a version of Python that
respects stable ordering of dicts (i.e. Python 3.7+)
Instead of relying on these implicitly, we now explicitly sort messages
by type number when the TLV sets.
Resolves#2956.
Thanks-To: @ScottTre for the sort function
Reported-By: @ZmnSCPxj
Rusty Russell
Simon Vrouwe
Damian Mee
darosior
lisa neigut
trueptolemy
ZmnSCPxj
Sjors Provoost