Closing a GeckoSession causes memory leaks
Categories
(GeckoView :: General, defect)
Tracking
(Not tracked)
People
(Reporter: gabrielstrong, Unassigned)
Details
Attachments
(1 file)
|
85.53 KB,
image/png
|
Details |
GeckoView-Main_and_Tab.PNG
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Steps to reproduce:
Repeatedly created and closed instances of GeckoSession and verified that all instances of GeckoSession were properly closed.
After a while Android ran out of available memory and the app was shut down.
Tested on x86_64 Android Emulator running Android 7.1 and Android 10.
This happens on the latest nightly version as well (91.0.20210701211644).
Actual results:
Created a test that opened and closed 100 GeckoSession instances sequentially.
Each session was allowed to open a URL and a GeckoSession.ProgressDelegate/onPageStop was used to trigger the next GeckoSession close/open.
No GeckoViews are necessary to run this leak test if a SurfaceView is provided instead (leak happens either way).
After all 100 GeckoSessions were closed the Android Studio Profiler was used to force full GC of all unreferenced objects (multiple times).
A heap dump shows that all GeckoSession instances were GC'd.
The same heap dump shows that several Gecko object instances were still alive with 101 allocations in both the main process and the Tab process.
The Tab process Gecko objects were:
GeckoEditableChild
IGeckoEditableParent$Stub$Proxy
GeckoEditableChild$RemoteChild
The Main process Gecko objects were:
GeckoEditable
GeckoEditable$AsyncText
GeckoEditableChild
PanZoomController
These Gecko object of course also leaked other Java objects that were being referenced.
Expected results:
When a GeckoSession is closed and GC'd there should be no leaks of objects created by the GeckoSession.
The number of leaked objects (like the GeckoEditableChild object) always go hand in hand with the number of sessions created/closed.
I'm not an expert in GeckoView nor all the JNI being used by it but it seems like these Gecko objects are being proxied between the JVM and the native C++ libraries and for some reason the JVM is unable to properly identify these objects as no longer referenced so they are never GC'd.
I'm providing screenshots of the heap dumps.
|
||
Comment 2•4 years ago
|
||
Thanks for the report Gabe! Looks like you're hitting Bug 1678425.
Description
•