Skip to content

Don't bump the next_node_counter when using a removed counter #3367

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions lightning/src/routing/gossip.rs
Original file line number Diff line number Diff line change
Expand Up @@ -2077,9 +2077,9 @@ where
},
IndexedMapEntry::Vacant(node_entry) => {
let mut removed_node_counters = self.removed_node_counters.lock().unwrap();
**chan_info_node_counter = removed_node_counters
.pop()
.unwrap_or(self.next_node_counter.fetch_add(1, Ordering::Relaxed) as u32);
**chan_info_node_counter = removed_node_counters.pop().unwrap_or_else(|| {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a call to test_node_counter_consistency to the end of this method? From local testing it looks like this would've caught the bug. Not sure if other methods could use it as well.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't appear to have any test coverage which removes then adds a channel, so even with a new check in this method none of our tests fail. Ultimately we end up panicing immediately when the next message comes in, though, so running a real node with debug assertions on hit this pretty quick :)

Copy link
Contributor

@valentinewallace valentinewallace Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I get two test failures with this diff (i.e. reverting the fix and adding the check):

diff --git a/lightning/src/routing/gossip.rs b/lightning/src/routing/gossip.rs
index 9d85a6c58..f761e6a63 100644
--- a/lightning/src/routing/gossip.rs
+++ b/lightning/src/routing/gossip.rs
@@ -2077,9 +2077,9 @@ where
                                },
                                IndexedMapEntry::Vacant(node_entry) => {
                                        let mut removed_node_counters = self.removed_node_counters.lock().unwrap();
-                                       **chan_info_node_counter = removed_node_counters.pop().unwrap_or_else(|| {
+                                       **chan_info_node_counter = removed_node_counters.pop().unwrap_or(
                                                self.next_node_counter.fetch_add(1, Ordering::Relaxed) as u32
-                                       });
+                                       );
                                        node_entry.insert(NodeInfo {
                                                channels: vec![short_channel_id],
                                                announcement_info: None,
@@ -2088,6 +2088,9 @@ where
                                },
                        };
                }
+               core::mem::drop(channels);
+               core::mem::drop(nodes);
+               self.test_node_counter_consistency();

                Ok(())
        }

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol, I'm an idiot, I ran the test without reverting the diff. I'll add this in a followup, anyway.

self.next_node_counter.fetch_add(1, Ordering::Relaxed) as u32
});
node_entry.insert(NodeInfo {
channels: vec![short_channel_id],
announcement_info: None,
Expand Down
Loading