]> git.bitcoin.ninja Git - rust-lightning/commitdiff
Don't bump the `next_node_counter` when using a removed counter 2024-10-dense-counters
authorMatt Corallo <git@bluematt.me>
Mon, 14 Oct 2024 16:54:56 +0000 (16:54 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 16 Oct 2024 22:45:10 +0000 (22:45 +0000)
If we manage to pull a `node_counter` from `removed_node_counters`
for reuse, `add_channel_between_nodes` would `unwrap_or` with the
`next_node_counter`-incremented value. This visually looks right,
except `unwrap_or` is always called, causing us to always increment
`next_node_counter` even if we don't use it.

This will result in the `node_counter`s always growing any time we
add a new node to our graph, leading to somewhat larger memory
usage when routing and a debug assertion failure in
`test_node_counter_consistency`.

The fix is trivial, this is what `unwrap_or_else` is for.

lightning/src/routing/gossip.rs

index 47d80d86cf7272aff98594903f59b4478f64defd..9d85a6c587b01970dc7a472768e9a873a69cfcef 100644 (file)
@@ -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(|| {
+                                               self.next_node_counter.fetch_add(1, Ordering::Relaxed) as u32
+                                       });
                                        node_entry.insert(NodeInfo {
                                                channels: vec![short_channel_id],
                                                announcement_info: None,