Added output_witscript field to sign_remote_commitment_tx #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When we're in remove_all_gossip, we *don't* call free_chan, but free it manually. This trips over the developer-mode check that we called free_chan! Make it also insert the magic so that destroy_chan_check passes: lightning_gossipd: gossipd/routing.c:496: destroy_chan_check: Assertion `chan->sat.satoshis == (u64)chan' failed. lightning_gossipd: FATAL SIGNAL 6 (version v0.7.3rc2-2-gf89d7c1) 0x5632436a4544 send_backtrace common/daemon.c:41 0x5632436a45ea crashdump common/daemon.c:54 0x7f053c3c7f5f ??? ???:0 0x7f053c3c7ed7 ??? ???:0 0x7f053c3a9534 ??? ???:0 0x7f053c3a940e ??? ???:0 0x7f053c3b9011 ??? ???:0 0x563243698b9d destroy_chan_check gossipd/routing.c:496 0x5632436dca46 notify ccan/ccan/tal/tal.c:235 0x5632436dcf35 del_tree ccan/ccan/tal/tal.c:397 0x5632436dd2c1 tal_free ccan/ccan/tal/tal.c:481 0x56324369f004 remove_all_gossip gossipd/routing.c:2981 0x563243692f5d gossip_store_load gossipd/gossip_store.c:772 0x56324368eff4 gossip_init gossipd/gossipd.c:872 0x563243690cbb recv_req gossipd/gossipd.c:1580 0x5632436a4a69 handle_read common/daemon_conn.c:31 0x5632436cc7ae next_plan ccan/ccan/io/io.c:59 0x5632436cd32b do_plan ccan/ccan/io/io.c:407 0x5632436cd369 io_ready ccan/ccan/io/io.c:417 0x5632436cf52f io_loop ccan/ccan/io/poll.c:445 0x56324369102f main gossipd/gossipd.c:1700 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There was a non-breakable space and a missing space in the error message for missing utxo params.
Reported-by: Simon Vrouwe <@SimonVrouwe> Signed-off-by: Christian Decker <@cdecker>
We were implicitly relying on sqlite3 behavior that returns the zero-value for nulled fields when accessing them. This adds the same behavior explicitly to the DB abstraction in order to reduce `db_column_is_null` checks in the logic, but still make it evident what is happening here. Fixes fiatjaf/mcldsp#1 Signed-off-by: Christian Decker <@cdecker>
We should never access a nulled field, so add an assert to that effect.
This was failing because the internal coin-selection doesn't go by insertion order when using postgres.
We were using `i` as index variable in two nested loops. This works as long as the DNS seed resolves to a single address, but will crash if the node has both an A as well as an AAAA entry, at which point we'll try to index the hostname without a matching entry. Signed-off-by: Christian Decker <@cdecker>
libwally really is pedantic about the kind of hints it will accept. Signed-off-by: Christian Decker <@cdecker>
I made some assumptions that turn out not to be true, mea culpa.
When probing, no point probing for before lightning became cool. Current logic means we often probe below block 500,000, and think things are OK because there are no short_channel_ids. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Asking for the last few blocks was logical, but my node is missing most gossip in practice. For the moment, simply ask a peer for every channel it knows, once we're started up. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These are fairly cheap, and it's important to make sure we're not missing gossip. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
new dependency for this build means we need it
Checking on whether we access a null field is ok, but should we crash right away? Probably not. This reduces the access to a warning on sqlite3 and let's it continue. We can look for occurences and fix them as they come up and then re-arm the asserts once we addressed all cases.
The case where this is needed is when the wallet had a forwarded payment somewhere between commits 66a47d2 (which started tracking forwardings) and d901304 (which added the `received_time` column). This just emulates the behavior of sqlite3 for postgres as well. Signed-off-by: Christian Decker <@cdecker>
lightning_gossipd(17421): MEMLEAK: 0x564b4b17b5a8
ligtning_gossipd(17421): label=gossipd/routing.c:1490:struct pending_node_announce
lightning_gossipd(17421): backtrace:
lightning_gossipd(17421): ccan/ccan/tal/tal.c:437 (tal_alloc_)
lightning_gossipd(17421): gossipd/routing.c:1490 (catch_node_announcement)
lightning_gossipd(17421): gossipd/routing.c:1837 (handle_channel_announcement)
lightning_gossipd(17421): gossipd/gossipd.c:238 (handle_channel_announcement_msg)
lightning_gossipd(17421): gossipd/gossipd.c:461 (peer_msg_in)
lightning_gossipd(17421): common/daemon_conn.c:31 (handle_read)
lightning_gossipd(17421): ccan/ccan/io/io.c:59 (next_plan)
lightning_gossipd(17421): ccan/ccan/io/io.c:407 (do_plan)
lightning_gossipd(17421): ccan/ccan/io/io.c:417 (io_ready)
lightning_gossipd(17421): ccan/ccan/io/poll.c:445 (io_loop)
lightning_gossipd(17421): gossipd/gossipd.c:1700 (main)
lightning_gossipd(17421): parents:
lightning_gossipd(17421): gossipd/routing.c:294:struct routing_state
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Whenever we have multi-connected nodes, out-of-order gossip is possible. In particular, if a node_announcement is 1 second fresher than the channel_announcement, a timestamp_filter might get one and not the other. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…does not have up-to-date infos" This reverts commit 7fd2f6d. We want to set 'complete' to false in future if we don't know everything!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: ElementsProject#3080 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A 'Bad commit_sig signature' was reported by @javier on Telegram and @darthcoin. This was between two c-lightning peers, so definitely our fault. Analysis of this message revealed the signature was using the wrong feerate. I finally managed to make a test case which triggered this. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ksedgwic
pushed a commit
that referenced
this pull request
May 2, 2021
Also, remove fuzz caused by varint->bigsize change. For some reason my build machine sorts patches into another order, and fails to patch: patching file wire/gen_onion_wire_csv.104951 Hunk #1 succeeded at 52 with fuzz 1 (offset -19 lines). patching file wire/gen_onion_wire_csv.104951 Hunk #1 FAILED at 8. 1 out of 1 hunk FAILED -- saving rejects to file wire/gen_onion_wire_csv.104951.rej make: *** [wire/Makefile:60: wire/gen_onion_wire_csv] Error 1 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ksedgwic
pushed a commit
that referenced
this pull request
May 2, 2021
e.g. in test_closing_id we can get a spend from the first (closed) channel in the same block as the open of the second. Half the time, we'll choose the wrong one as scid. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ksedgwic
pushed a commit
that referenced
this pull request
Sep 8, 2021
The variable `block` (instace of `struct block`) is
allocated on the stack without being initialized, i.e. its
member `prev` points to nowhere. This causes a segmentation
fault on my machine on the binding of "prev_hash" on running
`wallet_block_add`, as the following core-dump analysis
shows:
$ egdb ./wallet/test/run-wallet ./run-wallet.core
[...]
Core was generated by `run-wallet'.
Program terminated with signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---
#0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97
97 TLOOP1(*dst++ = *src++);
(gdb) bt
#0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97
#1 0x000008f73e838f60 in sqlite3VdbeMemSetStr () from /usr/local/lib/libsqlite3.so.37.12
#2 0x000008f73e83cb11 in bindText () from /usr/local/lib/libsqlite3.so.37.12
#3 0x000008f44bc91345 in db_sqlite3_query (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:77
#4 0x000008f44bc91122 in db_sqlite3_exec (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:110
#5 0x000008f44bcbb3b2 in db_exec_prepared_v2 (stmt=0x8f6845bf028) at ./wallet/db.c:2055
#6 0x000008f44bcc6890 in wallet_block_add (w=0x8f688b5bba8, b=0x7f7ffffca788) at ./wallet/wallet.c:3556
#7 0x000008f44bce2607 in test_wallet_outputs (ld=0x8f6a35a7828, ctx=0x8f6a35c0268) at wallet/test/run-wallet.c:1104
#8 0x000008f44bcddec0 in main (argc=1, argv=0x7f7ffffcaaf8) at wallet/test/run-wallet.c:1930
Fix by explicitely setting the whole structure to zero.
[ Rebuilt generated files, too --RR ]
ksedgwic
pushed a commit
that referenced
this pull request
Mar 3, 2023
This will fix a crash that I caused on armv7 and by looking inside the coredump with gdb (by adding an assert on n that must be different from null) I get the following stacktrace ``` (gdb) bt \#0 0x00000000 in ?? () \#1 0x0043a038 in send_backtrace (why=0xbe9e3600 "FATAL SIGNAL 11") at common/daemon.c:36 \#2 0x0043a0ec in crashdump (sig=11) at common/daemon.c:46 \#3 <signal handler called> \#4 0x00406d04 in node_announcement (map=0x938ecc, nann_off=495146) at common/gossmap.c:586 \#5 0x00406fec in map_catchup (map=0x938ecc, num_rejected=0xbe9e3a40) at common/gossmap.c:643 \#6 0x004073a4 in load_gossip_store (map=0x938ecc, num_rejected=0xbe9e3a40) at common/gossmap.c:697 \#7 0x00408244 in gossmap_load (ctx=0x0, filename=0x4e16b8 "gossip_store", num_channel_updates_rejected=0xbe9e3a40) at common/gossmap.c:976 \#8 0x0041a548 in init (p=0x93831c, buf=0x9399d4 "\n\n{\"jsonrpc\":\"2.0\",\"id\":\"cln:init#25\",\"method\":\"init\",\"params\":{\"options\":{},\"configuration\":{\"lightning-dir\":\"/home/vincent/.lightning/testnet\",\"rpc-file\":\"lightning-rpc\",\"startup\":true,\"network\":\"te"..., config=0x939cdc) at plugins/topology.c:622 \#9 0x0041e5d0 in handle_init (cmd=0x938934, buf=0x9399d4 "\n\n{\"jsonrpc\":\"2.0\",\"id\":\"cln:init#25\",\"method\":\"init\",\"params\":{\"options\":{},\"configuration\":{\"lightning-dir\":\"/home/vincent/.lightning/testnet\",\"rpc-file\":\"lightning-rpc\",\"startup\":true,\"network\":\"te"..., params=0x939c8c) at plugins/libplugin.c:1208 \#10 0x0041fc04 in ld_command_handle (plugin=0x93831c, toks=0x939bec) at plugins/libplugin.c:1572 \#11 0x00420050 in ld_read_json_one (plugin=0x93831c) at plugins/libplugin.c:1667 \#12 0x004201bc in ld_read_json (conn=0x9391c4, plugin=0x93831c) at plugins/libplugin.c:1687 \#13 0x004cb82c in next_plan (conn=0x9391c4, plan=0x9391d8) at ccan/ccan/io/io.c:59 \#14 0x004cc67c in do_plan (conn=0x9391c4, plan=0x9391d8, idle_on_epipe=false) at ccan/ccan/io/io.c:407 \#15 0x004cc6dc in io_ready (conn=0x9391c4, pollflags=1) at ccan/ccan/io/io.c:417 \#16 0x004cf8cc in io_loop (timers=0x9383c4, expired=0xbe9e3ce4) at ccan/ccan/io/poll.c:453 \#17 0x00420af4 in plugin_main (argv=0xbe9e3eb4, init=0x41a46c <init>, restartability=PLUGIN_STATIC, init_rpc=true, features=0x0, commands=0x6167e8 <commands>, num_commands=4, notif_subs=0x0, num_notif_subs=0, hook_subs=0x0, num_hook_subs=0, notif_topics=0x0, num_notif_topics=0) at plugins/libplugin.c:1891 \#18 0x0041a6f8 in main (argc=1, argv=0xbe9e3eb4) at plugins/topology.c:679 ``` I do not know if this is a solution because I do not know when I can parse a node announcement for a node that it is not longer in the gossip map. So, I hope this is just usefult for @rustyrussell Changelog-Fixed: fixes `FATAL SIGNAL 11` on gossmap node announcement parsing. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
ksedgwic
pushed a commit
that referenced
this pull request
Apr 21, 2023
The issue is that common_setup() wasn't called by the fuzz target,
leaving secp256k1_ctx as NULL.
UBSan error:
$ UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \
./fuzz-channel_id crash-1575b41ef09e62e4c09c165e6dc037a110b113f2
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 1153355603
INFO: Loaded 1 modules (25915 inline 8-bit counters): 25915 [0x563bae7ac3a8, 0x563bae7b28e3),
INFO: Loaded 1 PC tables (25915 PCs): 25915 [0x563bae7b28e8,0x563bae817c98),
./fuzz-channel_id: Running 1 inputs 1 time(s) each.
Running: crash-1575b41ef09e62e4c09c165e6dc037a110b113f2
bitcoin/pubkey.c:22:33: runtime error: null pointer passed as argument 1, which is declared to never be null
external/libwally-core/src/secp256k1/include/secp256k1.h:373:3: note: nonnull attribute specified here
#0 0x563bae41e3db in pubkey_from_der bitcoin/pubkey.c:19:7
#1 0x563bae4205e0 in fromwire_pubkey bitcoin/pubkey.c:111:7
#2 0x563bae46437c in run tests/fuzz/fuzz-channel_id.c:42:3
#3 0x563bae2f6016 in LLVMFuzzerTestOneInput tests/fuzz/libfuzz.c:23:2
#4 0x563bae20a450 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long)
#5 0x563bae1f4c3f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long)
#6 0x563bae1fa6e6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long))
#7 0x563bae223052 in main (tests/fuzz/fuzz-channel_id+0x181052) (BuildId: f7f56e14ffc06df54ab732d79ea922e773de1f25)
#8 0x7fa7fa113082 in __libc_start_main
#9 0x563bae1efbdd in _start
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bitcoin/pubkey.c:22:33 in
ksedgwic
pushed a commit
that referenced
this pull request
Aug 3, 2023
Detected by UBSan:
$ UBSAN_OPTIONS=print_stacktrace=1 ./wallet/test/run-psbt_fixup
bitcoin/psbt.c:733:2: runtime error: applying zero offset to null pointer
#0 0x53c829 in psbt_from_bytes lightning/bitcoin/psbt.c:733:2
#1 0x5adcb0 in main lightning/wallet/test/run-psbt_fixup.c:174:10
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bitcoin/psbt.c:733:2
ksedgwic
pushed a commit
that referenced
this pull request
Aug 3, 2023
The function is tiny and was only used in one location. And that one
location was leaking memory.
Detected by ASan:
==2637667==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x4cd758 in __interceptor_strdup
#1 0x64c70c in json_stream_log_suppress_for_cmd lightning/lightningd/jsonrpc.c:597:31
#2 0x68a630 in json_getlog lightning/lightningd/log.c:974:2
...
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
ksedgwic
pushed a commit
that referenced
this pull request
Aug 3, 2023
It is possible for db_column_bytes() to return 0 and for db_column_blob() to return NULL even when db_column_is_null() returns false. We need to short circuit in this case. Detected by UBSan: db/bindings.c:479:12: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here #0 0x95f117 in db_col_arr_ db/bindings.c:479:2 #1 0x95ef85 in db_col_channel_type db/bindings.c:459:32 #2 0x852c03 in wallet_stmt2channel wallet/wallet.c:1483:9 #3 0x81f396 in wallet_channels_load_active wallet/wallet.c:1749:23 #4 0x81f03d in wallet_init_channels wallet/wallet.c:1765:9 #5 0x72f1f9 in load_channels_from_wallet lightningd/peer_control.c:2257:7 #6 0x672856 in main lightningd/lightningd.c:1121:25
ksedgwic
pushed a commit
that referenced
this pull request
Aug 3, 2023
Fixes nullability errors detected by UBSan:
wire/fromwire.c:173:46: runtime error: null pointer passed as argument 1, which is declared to never be null
external/libwally-core/src/secp256k1/include/secp256k1.h:432:3: note: nonnull attribute specified here
#0 0x65214a in fromwire_secp256k1_ecdsa_signature wire/fromwire.c:173:6
#1 0x659500 in printwire_secp256k1_ecdsa_signature devtools/print_wire.c:331:1
#2 0x646ba2 in printwire_channel_update wire/peer_printgen.c:1900:7
#3 0x637182 in printpeer_wire_message wire/peer_printgen.c:128:11
#4 0x65a097 in main devtools/decodemsg.c:85:10
ksedgwic
pushed a commit
that referenced
this pull request
Aug 3, 2023
Memory leak detected by ASan:
==880002==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32816 byte(s) in 1 object(s) allocated from:
#0 0x5039e7 in malloc (lightningd/lightningd+0x5039e7)
#1 0x7f2e8c203884 in __alloc_dir (/lib64/libc.so.6+0xd2884)
ksedgwic
pushed a commit
that referenced
this pull request
Aug 3, 2023
Detected by ASan in test_hsmtool_generatehsm:
==58698==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 120 byte(s) in 1 object(s) allocated from:
#0 0x4e6247 in malloc
#1 0x7f078452d672 in getdelim
SUMMARY: AddressSanitizer: 120 byte(s) leaked in 1 allocation(s).
ksedgwic
pushed a commit
that referenced
this pull request
Aug 14, 2023
These show that we should clean up our notes. Here's the result from test_hardmpp: # we have computed a set of 1 flows with probability 0.328, fees 0msat and delay 23 # No MPP, so added 0msat shadow fee # Shadow route on flow 0/1 added 0 block delay. now 5 # sendpay flow groupid=1, partid=1, delivering=1800000000msat, probability=0.328 # Update chan knowledge scid=103x2x0, dir=0: [0msat,1799999999msat] # onion error WIRE_TEMPORARY_CHANNEL_FAILURE from node #1 103x2x0: failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) # we have computed a set of 2 flows with probability 0.115, fees 0msat and delay 23 # Shadow route on flow 0/2 added 0 block delay. now 5 # Shadow route on flow 1/2 added 0 block delay. now 5 # sendpay flow groupid=1, partid=3, delivering=500000000msat, probability=0.475 # sendpay flow groupid=1, partid=2, delivering=1300000000msat, probability=0.242 # Update chan knowledge scid=103x2x0, dir=0: [0msat,1299999999msat] # onion error WIRE_TEMPORARY_CHANNEL_FAILURE from node #1 103x2x0: failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) # we have computed a set of 2 flows with probability 0.084, fees 0msat and delay 23 # Shadow route on flow 0/2 added 0 block delay. now 5 # Shadow route on flow 1/2 added 0 block delay. now 5 # sendpay flow groupid=1, partid=5, delivering=260000000msat, probability=0.467 # sendpay flow groupid=1, partid=4, delivering=1040000000msat, probability=0.179 # Update chan knowledge scid=103x2x0, dir=0: [0msat,1039999999msat] # onion error WIRE_TEMPORARY_CHANNEL_FAILURE from node #1 103x2x0: failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) # we have computed a set of 2 flows with probability 0.052, fees 0msat and delay 23 # Shadow route on flow 0/2 added 0 block delay. now 5 # Shadow route on flow 1/2 added 0 block delay. now 5 # sendpay flow groupid=1, partid=7, delivering=120000000msat, probability=0.494 # sendpay flow groupid=1, partid=6, delivering=920000000msat, probability=0.105 Ideally it would look something like: # Computed 1 flows, probability=0.328: # Flow 1: 103x2x0 1800000000msat fee=0msat probability=0.328 shadow=+0msat/0blocks # Flow 1: FAIL: TEMPORARY_CHANNEL_FAILURE for 103x2x0. # Computed 2 flows, probability=0.115: # Flow 2: XXX->XXX 1300000000msat fee=XXX, probability=0.475 shadow=+0msat/0blocks # Flow 3: XXX->XXX 500000000msat fee=XXX, probability=0.475 shadow=+0msat/0blocks # Flow 2: FAIL: TEMPORARY_CHANNEL_FAILURE from node #1 103x2x0 # Computed 2 flows (3 total), probability=0.084, fee=0msat, delay=23 ... # Flow 4: SUCCESS, 2 in progress should succeed soon. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ksedgwic
pushed a commit
that referenced
this pull request
Aug 23, 2023
It now looks like (for test_hardmpp): ``` # we have computed a set of 1 flows with probability 0.328, fees 0msat and delay 23 # Flow 1: amount=1800000000msat prob=0.328 fees=0msat delay=12 path=-103x2x0/1(min=max=4294967295msat)->-103x5x0/0->-103x3x0/1-> # Flow 1: Failed at node #1 (WIRE_TEMPORARY_CHANNEL_FAILURE): failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) # Flow 1: Failure of 1800000000msat for 103x5x0/0 capacity [0msat,3000000000msat] -> [0msat,1799999999msat] # we have computed a set of 2 flows with probability 0.115, fees 0msat and delay 23 # Flow 2: amount=500000000msat prob=0.475 fees=0msat delay=12 path=-103x6x0/0(min=max=4294967295msat)->-103x1x0/1->-103x4x0/1-> # Flow 3: amount=1300000000msat prob=0.242 fees=0msat delay=12 path=-103x2x0/1(min=max=4294967295msat)->-103x5x0/0(max=1799999999msat)->-103x3x0/1-> # Flow 3: Failed at node #1 (WIRE_TEMPORARY_CHANNEL_FAILURE): failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) # Flow 3: Failure of 1300000000msat for 103x5x0/0 capacity [0msat,1799999999msat] -> [0msat,1299999999msat] # we have computed a set of 2 flows with probability 0.084, fees 0msat and delay 23 # Flow 4: amount=260000000msat prob=0.467 fees=0msat delay=12 path=-103x6x0/0(500000000msat in 1 htlcs,min=max=4294967295msat)->-103x1x0/1(500000000msat in 1 htlcs)->-103x4x0/1(500000000msat in 1 htlcs)-> # Flow 5: amount=1040000000msat prob=0.179 fees=0msat delay=12 path=-103x2x0/1(min=max=4294967295msat)->-103x5x0/0(max=1299999999msat)->-103x3x0/1-> # Flow 5: Failed at node #1 (WIRE_TEMPORARY_CHANNEL_FAILURE): failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) # Flow 5: Failure of 1040000000msat for 103x5x0/0 capacity [0msat,1299999999msat] -> [0msat,1039999999msat] # we have computed a set of 2 flows with probability 0.052, fees 0msat and delay 23 # Flow 6: amount=120000000msat prob=0.494 fees=0msat delay=12 path=-103x6x0/0(760000000msat in 2 htlcs,min=max=4294967295msat)->-103x1x0/1(760000000msat in 2 htlcs)->-103x4x0/1(760000000msat in 2 htlcs)-> # Flow 7: amount=920000000msat prob=0.105 fees=0msat delay=12 path=-103x2x0/1(min=max=4294967295msat)->-103x5x0/0(max=1039999999msat)->-103x3x0/1-> # Flow 7: Success ``` Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ksedgwic
pushed a commit
that referenced
this pull request
Oct 30, 2023
Adding an index means: 1. Add the new subsystem, and new updated_index field to the db, and create xxx_index_deleted/created/updated APIs. 2. Hook up these functions to the points they need to be called. 3. Add index, start and limit fields to the list command. 4. Add created_index and updated_index into the list command. This does #1. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
king-11
pushed a commit
that referenced
this pull request
May 1, 2025
We are supposed to allocate of the ctx we're passed, not tmpctx.
Doesn't matter for now, because we don't use this result with anything which outlives tmpctx,
but we're going to:
```
==47574==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040005a8f38 at pc 0x55d3c584d252 bp 0x7ffddfb1b090 sp 0x7ffddfb1b088
READ of size 8 at 0x6040005a8f38 thread T0
#0 0x55d3c584d251 in json_add_closed_channel /home/runner/work/lightning/lightning/lightningd/closed_channel.c:27:3
#1 0x55d3c584ca5a in json_listclosedchannels /home/runner/work/lightning/lightning/lightningd/closed_channel.c:118:3
#2 0x55d3c58c0cbe in command_exec /home/runner/work/lightning/lightning/lightningd/jsonrpc.c:808:8
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.