Open tubzby opened 2 weeks ago
From the output of tokio-console
, there are 2 tasks in warning state: "2 tasks have lost their waker", this might be the cause of leaks.
---EDIT 1-------
After adding some debug log, it seems there are an orphan task that never quit:
https://github.com/webrtc-rs/webrtc/blob/master/dtls/src/conn/mod.rs#L322
I'm stuck, but with some findings:
Client
created in gather_candiates_relay
was never dropped.PeerConnection
Agent
AgentInternal
were dropped.Candidate.close()
was called, but for UdpSocket
, it does nothing, it has to be dropped.It might related to the screenshot above, for some reason, the task created at agent_gather.rs:773 lost its waker, so the UdpSocket never released.
Update:
I have been using Arc::strong_count
to monitor Arc<CandidateBase>
and find out that the count is 6.
I created a tokio task to spy on it, so the actual reference count is 5 which causing this problem.
Finally, It leads to one possible line: https://github.com/webrtc-rs/webrtc/blob/23bbc1fb7eb9962e19e03cd4b8645e7aee8926c4/ice/src/agent/agent_transport.rs#L244
AgentConn::checklist
should be cleared on close
.
But there is still 1 leaking UdpSocket.
Great catch, could you submit a PR to fix it? Thanks
No problem, will submit a PR if there are no more leaks.
Anyway, I was doing Arc::strong_count
to tackle this, is there a better way to do that?
Addition to: https://github.com/webrtc-rs/webrtc/issues/608#issuecomment-2322699742
AgentConn.selected_pair
should also be cleared.
mdns.query
is never quit.
@rainliu There's a TODO comment line here, what's your suggestion?
I'm quite confused about why we should release these structures manually, is there a reference loop for Arc
?
I have a program working as a proxy to convert RTSP stream to WebRTC stream so I can visit my cameras on the browser, normally a connection is closed when I close the tab, and I'm monitoring the ICE state to close PeerConnection, every time I call
PeerConnection.close().await
it complains:and all the UDP socket is never closed, I have confirmed that by
lsof -n -p $pid
.