From 4144fef413fe604d16a6eaeb57ae45716ca1f587 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Tue, 13 Oct 2020 14:28:09 +1030 Subject: [PATCH] lightningd: fix crash when we try to send fail_htlc msg to onchaind. Great report from whitslack on this crash at startup: ``` 2020-10-07T13:03:21.419Z **BROKEN** lightningd: FATAL SIGNAL 6 (version 0.9.1) 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: common/daemon.c:51 (crashdump) 0x559fb67bcc76 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: /var/tmp/portage/sys-libs/glibc-2.32-r2/work/glibc-2.32/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 ((null)) 0x7f61cdca8baf 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: ../sysdeps/unix/sysv/linux/raise.c:50 (__GI_raise) 0x7f61cdca8b31 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: /var/tmp/portage/sys-libs/glibc-2.32-r2/work/glibc-2.32/stdlib/abort.c:79 (__GI_abort) 0x7f61cdc92535 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: /var/tmp/portage/sys-libs/glibc-2.32-r2/work/glibc-2.32/assert/assert.c:92 (__assert_fail_base) 0x7f61cdc9241e 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: /var/tmp/portage/sys-libs/glibc-2.32-r2/work/glibc-2.32/assert/assert.c:101 (__GI___assert_fail) 0x7f61cdca1241 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: lightningd/subd.c:750 (subd_send_msg) 0x559fb67a1c31 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: lightningd/subd.c:745 (subd_send_msg) 0x559fb67a1c31 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:252 (local_fail_in_htlc) 0x559fb6798f77 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:1441 (onchain_failed_our_htlc) 0x559fb6798f77 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: lightningd/onchain_control.c:339 (handle_missing_htlc_output) 0x559fb6786b9d 2020-10-07T13:03:21.419Z **BROKEN** lightningd: backtrace: lightningd/onchain_control.c:455 (onchain_msg) 0x559fb6786b9d ``` The problem is a channel with an onchaind can be in state FUNDING_STATE_SEEN, because onchaind has started but not responded to init yet (which it does once it has analyzed the commitment tx). Channel B is onchain, and its onchaind fails the HTLC, and we try to send a msg to channel A's onchaind as if it were channeld. Explicitly check if it's channeld, rather than trying to see if it's onchaind. Fixes: #4114 Signed-off-by: Rusty Russell Changelog-Fixed: crash: assertion fail at restart when source and destination channels of an HTLC are both onchain. --- lightningd/peer_htlcs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lightningd/peer_htlcs.c b/lightningd/peer_htlcs.c index 11c649adaad4..83bc4d0b5b79 100644 --- a/lightningd/peer_htlcs.c +++ b/lightningd/peer_htlcs.c @@ -141,7 +141,7 @@ static void tell_channeld_htlc_failed(const struct htlc_in *hin, return; /* onchaind doesn't care, it can't do anything but wait */ - if (channel_on_chain(hin->key.channel)) + if (!channel_active(hin->key.channel)) return; subd_send_msg(hin->key.channel->owner,