Open Bug 1577192 Opened 2 months ago Updated 11 days ago

Crash in [@ java.lang.OutOfMemoryError: at dalvik.system.VMRuntime.newNonMovableArray(Native Method)]

Categories

(GeckoView :: General, defect, P1, critical)

69 Branch
Unspecified
Android
defect

Tracking

(firefox69 wontfix, firefox70 wontfix, firefox71 affected)

Tracking Status
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- affected

People

(Reporter: marcia, Assigned: droeh)

References

Details

(Keywords: crash, regression, Whiteboard: [geckoview:m1909] [geckoview:m1910])

Crash Data

+++ This bug was initially created as a clone of Bug #1569312 +++

Creating a new bug since this signature appears to be the #2 crash in Fenix according to https://crash-stats.mozilla.com/topcrashers/?product=Fenix&version=69.0b0&process_type=any

It also appears to be a different stack than what is showing for the Fennec bug.
Bug 1569312#c4 has a good summary of what we think is happening in Fenix.

java.lang.OutOfMemoryError: Failed to allocate a 7115052 byte allocation with 4967648 free bytes and 4MB until OOM
	at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
	at android.graphics.Bitmap.nativeCreate(Native Method)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:843)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:820)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:787)
	at org.mozilla.gecko.GeckoThread.runUiThreadCallback(Native Method)
	at org.mozilla.gecko.GeckoThread$1.run(GeckoThread.java:2)
	at android.os.Handler.handleCallback(Handler.java:742)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:157)
	at android.app.ActivityThread.main(ActivityThread.java:5601)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:774)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:652)

The GV team's theory is that Fenix is probably taking page screenshots more often than they need. Is Fenix destroying the screenshot Bitmaps? Do we reuse the Bitmap? But would that screenshot theory explain why Fennec is affected? There were over 1500 Fennec crash reports with this signature last week.

The crash spiked in mid-July, which is when we released ARM64 Fennec 68. It's surprising that we would see more more OOMs on ARM64. See a similar stack trace from Fenix crash bug 1574992.

See Also: → 1569312
Duplicate of this bug: 1574992
See Also: → 1577526

Adding this bug to GV's September sprint because this is a top crash in Fenix

Emily is investigating.

Assignee: nobody → etoop
Priority: P2 → P1
Whiteboard: [geckoview:fenix:m8] → [geckoview:m1909]

AndroidComponents only takes a screenshot on Page Load Stop, which should not be too many calls, and then discards the Bitmap. Fenix does nothing different here, as they don't use screenshots in the tabs tray, only site icons.

However, considering that Fenix doesn't use the screenshots, there seems no need to continue to take them on page load stop. AC has been updated to make this only occur when the ThumbnailsFeature is enabled, but Fenix currently has that feature enabled. I believe this is intended to be disabled as it is unused.

All in all, this is unlikely to be caused by screenshotting in GeckoView and soon this feature will be disabled in Fenix anyway.

The GV interface to capture the contents of GeckoView is provided by GeckoView.capturePixels(). This calls requestScreenPixels in the Compositor which hooks into the renderer. This hook captures the requested data and then calls back into Java for a Bitmap object to copy the data into. The Bitmap object is than passed back as a result.

The allocation of the Bitmap object in Java is where the OOM crash occurs.
The typical maximum size of the Java heap on android is 36MB so larger render captures are in danger of blowing the heap.
This allocation is hindered by:
  The allocation must be contiguous so a fragmented heap effectively reduces available memory.
  The allocation can be effectively the full screen of a device. On a 4k device this would require just less than 32MB of contiguous heap.
  There is no way to pass in an existing Bitmap object for re-use or recycling.

It is suggested that this functionality is replaced with something that minimises memory usage and allows for the Java allocation to be controlled by the App.
For the API, a Screenshot class is suggested to be used and returned instead of Bitmap object.
The class would provide calls for requesting bitmap objects, image regions and scaling; Allowing for bitmaps to be passed as arguments as a draw target or for memory recycling/reuse.

Assignee: etoop → estirling

Tracking for GV's October sprint. Dylan says he will pick up Elliot's patch.

IIUC, Fenix is taking screenshots, but not actually using them. FxR plans to start using screenshots soon.

Assignee: estirling → droeh
Whiteboard: [geckoview:m1909] → [geckoview:m1910]
Whiteboard: [geckoview:m1910] → [geckoview:m1909] [geckoview:m1910]
You need to log in before you can comment on or make changes to this bug.