Open MartinP7r opened 4 years ago
That's a lot of instances. Are you leaving the room only once or are you entering/exiting the room multiple times? Also on entering the room how many streams are you viewing?
At time of screenshot I left and rejoined a bunch of times with several other streams in the mix. I did it again, leaving only once, with one other client in the room (audio, video). e.g. 2 producers, 2 consumers.
Thanks will look into when I get the time.
Thanks!
Also I'm just curious if you're experiencing the same with your sample app?
Can reproduce, will look into it.
Reduced quite a few of the leaks. However I am not able to reduce the leaks coming from the WebRTC framework. Will try to reduce the mediasoup leaks.
@MartinP7r Hello could you try version 1.5.4 and see if it reduces some of the leaks?
Sorry, it's still the same in terms of memory consumed and not being released when closing the connection.
First thing I realized with 1.5.4
I'm getting a Thread 1: EXC_BAD_ACCESS (code=1, address=0x1)
error when trying to close the local producer with producer?.close()
as the first action when leaving the room. This didn't happen before.
The memory consumption and amount of memory kept after leaving the room did not change. However the number of leaked instance down for mediasoup went down considerably, but there's still an instance of each RecvTransport and SendTransport leaked.
eCOMET - 396 Group
Memory Issues - (38 leaked types) Group
runtime: Memory Issues - (38 leaked types): 1 instance of __NSCFArray leaked
runtime: Memory Issues - (38 leaked types): 2 instances of __NSCFSet leaked
runtime: Memory Issues - (38 leaked types): 3 instances of __NSCFString leaked
runtime: Memory Issues - (38 leaked types): 1 instance of __NSExactBlockVariable__ leaked
runtime: Memory Issues - (38 leaked types): 2 instances of __NSMallocBlock__ leaked
runtime: Memory Issues - (38 leaked types): 1 instance of __NSSingleEntryDictionaryI leaked
runtime: Memory Issues - (38 leaked types): 1 instance of CFRunLoop leaked
runtime: Memory Issues - (38 leaked types): 1 instance of CFRunLoopMode leaked
runtime: Memory Issues - (38 leaked types): 1 instance of CFRunLoopSource leaked
runtime: Memory Issues - (38 leaked types): 2 instances of CFSet (Value Storage) leaked
runtime: Memory Issues - (38 leaked types): 2 instances of cricket::AudioCodec leaked
runtime: Memory Issues - (38 leaked types): 2 instances of cricket::AudioContentDescription leaked
runtime: Memory Issues - (38 leaked types): 4 instances of cricket::VideoCodec leaked
runtime: Memory Issues - (38 leaked types): 6 instances of cricket::VideoContentDescription leaked
runtime: Memory Issues - (38 leaked types): 18 instances of NSConcreteValue leaked
runtime: Memory Issues - (38 leaked types): 1 instance of NSURL leaked
runtime: Memory Issues - (38 leaked types): 1 instance of OS_dispatch_source leaked
runtime: Memory Issues - (38 leaked types): 1 instance of RecvTransport leaked
runtime: Memory Issues - (38 leaked types): 8 instances of rtc::RefCountedObject<rtc::BufferT<unsigned char, false> > leaked
runtime: Memory Issues - (38 leaked types): 3 instances of RTCRtpEncodingParameters leaked
runtime: Memory Issues - (38 leaked types): 1 instance of SendTransport leaked
runtime: Memory Issues - (38 leaked types): 6 instances of webrtc::JsepCandidateCollection leaked
runtime: Memory Issues - (38 leaked types): 5 instances of webrtc::JsepIceCandidate leaked
runtime: Memory Issues - (38 leaked types): 6 instances of webrtc::JsepSessionDescription leaked
edit: random side-question: Mediasoupclient.initialize()
doesn't seem to be necessary? At least I don't see any difference whether I call it or not.
First thing I realized with 1.5.4 I'm getting a Thread 1: EXC_BAD_ACCESS (code=1, address=0x1) error when trying to close the local producer with producer?.close() as the first action when leaving the room. This didn't happen before.
The native producer object now gets released from memory when you call close, so you cannot reference the producer after close. A release method could be added just for releasing but the API will increase :/
but there's still an instance of each RecvTransport and SendTransport leaked.
These can be released, however I don't think the webrtc leaks can be fixed easily...
edit: random side-question: Mediasoupclient.initialize() doesn't seem to be necessary? At least I don't see any difference whether I call it or not.
The method no longer exists so you shouldn't need to call it.
The native producer object now gets released from memory when you call close, so you cannot reference the producer after close. A release method could be added just for releasing but the API will increase :/
I'm not sure I understand you correctly, but the EXC_BAD_ACCESS
occurs when calling .close()
, not when referencing it after closing. Btw, same thing happens with sendTransport and recvTransport. Is it best to close the producer and transports just by assigning nil
to the property and not calling .close()
on it?
but there's still an instance of each RecvTransport and SendTransport leaked.
These can be released, however I don't think the webrtc leaks can be fixed easily...
Can you specify how to properly release them?
edit: random side-question: Mediasoupclient.initialize() doesn't seem to be necessary? At least I don't see any difference whether I call it or not.
The method no longer exists so you shouldn't need to call it.
My bad, thanks for clarifying!
Hello @ethand91 , I am facing the same issue. I can close rcvTransport. But I cannot close sendTransport. It crashes the app. Same crash as @MartinP7r
Thanks in advance,
I opened this PR that is related to memory leaks. https://github.com/ethand91/mediasoup-ios-client/pull/104
When I leave a room (closing and removing all producers, consumers, transports). About 30mb of memory are not being released.
I was wondering if you've been experiencing the same?
Below some screenshots of my runtime memory view:
(I'd also post your
Logger
's data, but seems to be to much data for github to display. If you need it i'll find another way)