Lightningd crash after overpayment

[Lagrang3]

Issue and Steps to Reproduce

In regtest trying to over-pay a multipart payment, the recipient crashes. Head at d716e6db734c62610432b7d703cb6bddd22016c3.

Steps to reproduce

start_ln 5
fund_nodes
export INV=$(l4-cli invoice 100000sat `date +"%s"` inv | jq -r .bolt11)
export DEST=`l1-cli decode $INV | jq -r .payee`
export HASH=`l1-cli decode $INV | jq -r .payment_hash`
export SECRET=`l1-cli decode $INV | jq -r .payment_secret`
l1-cli -k sendpay route=`l1-cli getroute $DEST 50000sat 10 | jq -c .route` payment_hash=$HASH payment_secret=$SECRET groupid=1 partid=1 amount_msat=100000sat
l1-cli -k sendpay route=`l1-cli getroute $DEST 40000sat 10 | jq -c .route` payment_hash=$HASH payment_secret=$SECRET groupid=1 partid=2 amount_msat=100000sat
l1-cli -k sendpay route=`l1-cli getroute $DEST 50000sat 10 | jq -c .route` payment_hash=$HASH payment_secret=$SECRET groupid=1 partid=3 amount_msat=100000sat

this results in l4 crashing with the following dump

$ lightningd: FATAL SIGNAL 6 (version v23.11-377-gc6ae037-modded)
0x55d4f80afb88 send_backtrace
	common/daemon.c:33
0x55d4f80afc10 crashdump
	common/daemon.c:75
0x7f6c61c40fcf ???
	./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f6c61c8fd3c __pthread_kill_implementation
	./nptl/pthread_kill.c:44
0x7f6c61c40f31 __GI_raise
	../sysdeps/posix/raise.c:26
0x7f6c61c2b471 __GI_abort
	./stdlib/abort.c:79
0x55d4f8225d2f call_error
	ccan/ccan/tal/tal.c:95
0x55d4f8225dd8 check_bounds
	ccan/ccan/tal/tal.c:169
0x55d4f8225e09 to_tal_hdr
	ccan/ccan/tal/tal.c:179
0x55d4f822678f tal_free
	ccan/ccan/tal/tal.c:514
0x55d4f8052e09 htlc_set_add
	lightningd/htlc_set.c:212
0x55d4f807c0d5 handle_localpay
	lightningd/peer_htlcs.c:469
0x55d4f807d4a2 htlc_accepted_hook_final
	lightningd/peer_htlcs.c:1158
0x55d4f8084db5 plugin_hook_call_next
	lightningd/plugin_hook.c:194
0x55d4f8084f75 plugin_hook_callback
	lightningd/plugin_hook.c:169
0x55d4f807f6ae plugin_response_handle
	lightningd/plugin.c:661
0x55d4f8082e15 plugin_read_json_one
	lightningd/plugin.c:773
0x55d4f80830b1 plugin_read_json
	lightningd/plugin.c:824
0x55d4f821acd7 next_plan
	ccan/ccan/io/io.c:59
0x55d4f821b15e do_plan
	ccan/ccan/io/io.c:407
0x55d4f821b1f7 io_ready
	ccan/ccan/io/io.c:417
0x55d4f821ca54 io_loop
	ccan/ccan/io/poll.c:453
0x55d4f8057475 io_loop_with_timers
	lightningd/io_loop_with_timers.c:22
0x55d4f805c9b7 main
	lightningd/lightningd.c:1423
0x7f6c61c2c1c9 __libc_start_call_main
	../sysdeps/nptl/libc_start_call_main.h:58
0x7f6c61c2c284 __libc_start_main_impl
	../csu/libc-start.c:360
0x55d4f8031f10 ???
	???:0
0xffffffffffffffff ???
	???:0

It is weird that I am not able to reproduce it every time, I will try to make a pyln-testing for this.

[cdecker]

This indicates a double-free:

0x55d4f8225dd8 check_bounds
	ccan/ccan/tal/tal.c:169
...
0x55d4f822678f tal_free
	ccan/ccan/tal/tal.c:514
0x55d4f8052e09 htlc_set_add

So it could be a dangling reference to the set somewhere after it has already been completed.