Remove a race-y debug assertion in new channel update handling 2023-04-fix-panicy-debug-assert
authorMatt Corallo <git@bluematt.me>
Sun, 9 Apr 2023 01:43:39 +0000 (01:43 +0000)
committerMatt Corallo <git@bluematt.me>
Sun, 9 Apr 2023 01:43:39 +0000 (01:43 +0000)
In 6090d9e6a862a2010eb80be56b7449947bc08374 we swapped out old
debug assertions that checked that a lock was `try_lock`able to
test that certain locks weren't held when we needed to be able to
take them in some near branch. However, another slipped in after in
the `ChannelMonitorUpdate` handling rework, which is replaced with
the new debug assertions here.

lightning/src/ln/channelmanager.rs

index 530532a1e4a5adb921b92f83f332014b11c9ef02..8c8450f6dce2a92bcfe402c7608d27cf9f5b60f5 100644 (file)
@@ -1588,7 +1588,7 @@ macro_rules! handle_new_monitor_update {
        ($self: ident, $update_res: expr, $update_id: expr, $peer_state_lock: expr, $peer_state: expr, $per_peer_state_lock: expr, $chan: expr, MANUALLY_REMOVING, $remove: expr) => { {
                // update_maps_on_chan_removal needs to be able to take id_to_peer, so make sure we can in
                // any case so that it won't deadlock.
-               debug_assert!($self.id_to_peer.try_lock().is_ok());
+               debug_assert_ne!($self.id_to_peer.held_by_thread(), LockHeldState::HeldByThread);
                match $update_res {
                        ChannelMonitorUpdateStatus::InProgress => {
                                log_debug!($self.logger, "ChannelMonitor update for {} in flight, holding messages until the update completes.",