Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
We hit: assert(!peer->handle_master_reply); #4 0x000055bba3b030a0 in master_sync_reply (peer=0x55bba41c0030, msg=0x55bba41c6a80 "", replytype=WIRE_CHANNEL_GOT_COMMITSIG_REPLY, handle=0x55bba3b041cf <handle_reply_wake_peer>) at channeld/channel.c:518 #5 0x000055bba3b049bc in handle_peer_commit_sig (conn=0x55bba41c10d0, peer=0x55bba41c0030, msg=0x55bba41c6a80 "") at channeld/channel.c:959 #6 0x000055bba3b05c69 in peer_in (conn=0x55bba41c10d0, peer=0x55bba41c0030, msg=0x55bba41c67c0 "") at channeld/channel.c:1339 #7 0x000055bba3b123eb in peer_decrypt_body (conn=0x55bba41c10d0, pcs=0x55bba41c0030) at common/cryptomsg.c:155 #8 0x000055bba3b2c63b in next_plan (conn=0x55bba41c10d0, plan=0x55bba41c1100) at ccan/ccan/io/io.c:59 We got a commit_sig from the peer while waiting for the master to reply to acknowledge the commitsig we want to send (handle_sending_commitsig_reply). The fix is to go always talk to the master synchronous, and not try to process anything but messages from the master daemon. This avoids the whole class of problems. There's a fairly simple way to do this, as ccan/io lets you override its poll call: we process any outstanding master requests there, or add the master fd to the pollfds array. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Loading branch information