notifications: Investigate possible memory leak with pending outbound substream tracking #295
Labels
bug
Something isn't working
Comments
lexnv
added a commit
that referenced
this issue
Dec 3, 2024
This PR fixes a subtle memory leak that can happen in the following edge-case situation: - connection is established and substream outbound is initiated with remote peer - the substream ID is tracked until the substream either completes successfully or fails - the connection is closed soon after, leading to no substream events ever being generated For this edge-cases, we need to remove the tracking of the substream ID when the connection is reported as closed. This has been detected after running a node for more than 2 days with the following generic metrics PR: - #294 Closes: #295 cc @paritytech/networking --------- Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The metrics implementation exposed an abnormal behaviour in our state tracking:
It looks like the following data structure grows over time:
litep2p/src/protocol/notification/mod.rs
Lines 261 to 262 in 28d42c6
Elements are added to the hashmap on:
litep2p/src/protocol/notification/mod.rs
Line 919 in 28d42c6
litep2p/src/protocol/notification/mod.rs
Line 1093 in 28d42c6
Elements are removed from the hashmap on:
litep2p/src/protocol/notification/mod.rs
Line 514 in 28d42c6
litep2p/src/protocol/notification/mod.rs
Line 816 in 28d42c6
Possible causes
It looks like we should remove the state on the connection closed as well:
litep2p/src/protocol/notification/mod.rs
Line 445 in 28d42c6
The text was updated successfully, but these errors were encountered: