]> git.bitcoin.ninja Git - rust-lightning/commitdiff
Don't bump the `next_node_counter` when using a removed counter
authorMatt Corallo <git@bluematt.me>
Mon, 14 Oct 2024 16:54:56 +0000 (16:54 +0000)
committerMatt Corallo <git@bluematt.me>
Mon, 14 Oct 2024 16:54:56 +0000 (16:54 +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 f1bc73110bf9d6a24065cb339e0f88141e2d7798..bb14adefe07f57cc443eaa12134cb91184a17bda 100644 (file)
@@ -1898,7 +1898,9 @@ impl<L: Deref> NetworkGraph<L> where L::Target: Logger {
                                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);
+                                               .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,