You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
webrtc-java 0.8.0. Callback instances (all XxxObservers passed to PeerConnectionFactory.createPeerConnection and such) are constantly leaking. In my case I need to create a large number of PCs in a long-running monitoring application which started to eat memory after migration from ice4j to webrtc-java. Heap dump analysis revealed that observers are kept alive by native code (GC Root: Global JNI).
After leak created message is printed, LeakTestJava$1 is in the top-1 by retained memory size.
Expected behavior
Observers should not leak.
Desktop (please complete the following information):
OS: Ubuntu
Version 23.10
Additional context
One suspicious place where the leak is possible is JNI code that passes a pointer to rtc::RefCountedObjects to native webrtc APIs without releasing initial reference.
The text was updated successfully, but these errors were encountered:
Describe the bug
webrtc-java 0.8.0. Callback instances (all
XxxObserver
s passed toPeerConnectionFactory.createPeerConnection
and such) are constantly leaking. In my case I need to create a large number of PCs in a long-running monitoring application which started to eat memory after migration from ice4j to webrtc-java. Heap dump analysis revealed that observers are kept alive by native code (GC Root: Global JNI).To Reproduce
Minimal reproducer:
After
leak created
message is printed,LeakTestJava$1
is in the top-1 by retained memory size.Expected behavior
Observers should not leak.
Desktop (please complete the following information):
Additional context
One suspicious place where the leak is possible is JNI code that passes a pointer to
rtc::RefCountedObject
s to native webrtc APIs without releasing initial reference.The text was updated successfully, but these errors were encountered: