chrome memory leak when entering and exiting a room frequently
kingpeter2015 opened this issue · comments
Bug Report
chrome memory leak when entering a room and exiting a room frequently.
Environment
- Operating system:
- Server: Centos 6.5
- Client: Windows 10/11
- Browser version: Chrome 108.0.5359.125
- npm version: 8.19.1
- mediasoup version: 3.10.4
- mediasoup-demo: 3.0.0
- mediasoup-client version: 3.6.54
Issue description
According to mediasoup-demo, I deployed local mediasoup-demo successfully. Then I opened the chrome browser under my windows computer, and did the following operations :
- (1) Open a chrome new tab (marked as Tab1) with a link address such as https://v3demo.mediasoup.org/?roomId=atptze2k
- (2) Then, open another chrome tab (marked as Tab2) with the same link address https://v3demo.mediasoup.org/?roomId=atptze2k.
Entering the same room atptze2k - (3) Close tab2, redo the above step (2), open another tab2
- (4) Repeat the above two steps (2), (3)
Then I found the memory of tab1 continues to grow from 170m to 200m. After about 8 hours later, the consumed memory reached more than 600m. It is conceivable that if this operation continues, the memory will continue to grow.
We guess mediasoup-client api consume.close() did not actually destroy the track of webrtc when another peer was exiting room, or wonder if mediasoup-client api transport.close() will recycle all resource of consumers or producers under this transport. But We are not sure what is causing this memory leak.
Is this report exactly the same as this one? #236
If so, why a duplicate report?
I assume it's the same. So there is something that I told in that issue which was not taken into account:
Is such a snippet code based on mediasoup-demo client side code? If so, I don't think it's cleaning up all the required stuff when closing a consumer so the leak is due to the demo app itself. I cannot consider this report valid unless proper reproducing code is provided.
We guess mediasoup-client api
consume.close()did not actually destroy the track of webrtc when another peer was exiting room
There are no "peers" in mediasoup or mediasoup-client but just transports and producers and consumers. I don't know what "destroy a track" is. Definitely consumer.close() calls track.stop() (see close() method in Consumer.ts in mediasoup-client.
I've tried the same scenario in Google Meet and it behaves the same way. BTW free memory is just deallocated when the OS needs it, so this is a normal thing in any Linux/BSD based system.
Said that, testing these things with the mediasoup-demo doesn't have much value. I don't know if there is a leak in the mediasoup-demo code (maybe). Still I see same memory usage in Google Meet when the remote peer reconnects over and over.
From mediasoup-client side everything is ok. When consumer.close() is called, the remote track is stopped and the corresponding section of the remote SDP is later recycled/reused for a new remote consumer. Everything is good.
I test same scenario. Memory continue to grow and eventually causes the browser to crash after thousands of join and leave room.
I test same scenario. Memory continue to grow and eventually causes the browser to crash after thousands of join and leave room.
Can you identify where such a leak happens? Because I am 90% sure that it's a leak in the app rather than in mediasoup-client.
webrtc_internals_dump (1).txt
I think it's not leak in the app as showed from the picture.
I upload dump after 100 times join and leave room in another host.
Nothing in that picture indicates that the problem is in mediasoup-client.
Guys, I already spent time checking the whole mediasoup-client code and I didn't find any leak. So if I'm wrong and someone can identify a leak, please say it. I don't know what else I can do. Until now there are zero evidences telling that mediasoup-client leaks.
Hi guys, if someone can prove that there is a memory leak (in mediasoup-client rather than in the mediasoup-demo app), please provide proper data here demonstrating it. The only I see are some assumptions based on mediasoup-demo and some random logs and graphs that are thrown here for me to verify whether they make sense or not.