Closed Bug 1507427 Opened Last year Closed 9 months ago

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

Categories

(Firefox for Android :: General, defect, P2, critical)

Firefox 65
ARM
Android
defect

Tracking

()

RESOLVED FIXED
Firefox 67
Tracking Status
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- fixed

People

(Reporter: levente.sacal, Assigned: petru)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is
report bp-7050ef6f-bb22-4f99-96f0-38fc30181114.
=============================================================

Java stack trace:

java.lang.OutOfMemoryError
	at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
	at android.graphics.Bitmap.nativeCreate(Native Method)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:879)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:856)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:823)
	at org.mozilla.gecko.BrowserApp.getBitmapOfToolbarChrome(BrowserApp.java:1592)
	at org.mozilla.geckoview.DynamicToolbarAnimator.handleToolbarAnimatorMessage(DynamicToolbarAnimator.java:158)
	at org.mozilla.geckoview.GeckoSession.handleCompositorMessage(GeckoSession.java:4054)
	at org.mozilla.geckoview.GeckoSession$Compositor.recvToolbarAnimatorMessage(GeckoSession.java:211)
	at org.mozilla.gecko.GeckoThread.runUiThreadCallback(Native Method)
	at org.mozilla.gecko.GeckoThread$1.run(GeckoThread.java:113)
	at android.os.Handler.handleCallback(Handler.java:751)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:241)
	at android.app.ActivityThread.main(ActivityThread.java:6217)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)


Device(s):
 -  Sony Xperia Z5 (Android 7.0);


Build(s):
 - Nightly 65.0a1 (2018-11-14);

Steps to reproduce:
 1. Log in to Reddit
 2. Crash after log into Reddit
Moderate volume but maybe we have a chance to fix this with clear STR.
Whiteboard: [geckoview]

It looks like we're creating a new bitmap every time we need to take a snapshot of the toolbar, which is not very good.

This is a Fennec-only OOM crash. GV doesn't use this bitmap code.

Whiteboard: [geckoview]

Adding 67 as affected.

Assignee: nobody → petru.lingurar
Status: NEW → ASSIGNED

There certainly seems to be a spike of this Bitmap related crashes from around 6th of October but I think they are just the effect of some other bigger issues. Which may or may not be actual leaks in code. Something else eats the memory and when the app (seemingly behaving normally) tries to allocate space for Bitmaps (common operation) it crashes because there is too little memory left.

By looking through the resports I see the following main Bitmap OOM scenarios:
1 - BrowserApp.getBitmapOfToolbarChrome [1] - creating an image of the toolbar to be animated.
https://crash-stats.mozilla.com/report/index/7050ef6f-bb22-4f99-96f0-38fc30181114
I profiled the app and saw that even if in the current implementation we are creating a new bitmap every time we need to hide the toolbar this should't really cause any issues as we are not leaking it and it's size is around 1MB (depending on the device's resolution) so it shouldn't really be problematic.
We can wrap that bitmap creation in a try-catch so that in the case of an exception it would not crash the app but the toolbar simply would not be hidden.
2 - TabsPanelThumbnailView.setImageDrawable [2] - getting a page thumbnail to be shown in the tabs panel
https://crash-stats.mozilla.com/report/index/76ca1927-b5ad-4ea9-8e7f-5f68f0190226
No real memory pressure. Small bitmaps that will be shown inside a RecycleView.
We can wrap that bitmap creation in a try-catch so that in the case of an exception it would not crash the app but the tab thumbnail would be blank.
3 - GeckoMediaControlAgent.generateCoverArt [3] - getting the default large icon for the media notification
https://crash-stats.mozilla.com/report/index/ee1fb882-c4b5-4c01-8fcc-897780190226
As seen in the crash reports this doesn't exceed 1MB in size so it shouldn't be an issue on it's own.
4 - BrowserApp.resolveBookmarkIconDrawable [4] - getting a drawable from app's resources
https://crash-stats.mozilla.com/report/index/0367b2d0-4498-46e5-b218-efd240190226
As seen in the crash reports this doesn't exceed 1MB in size so it shouldn't be an issue on it's own. Also the code related to this hasn't been recently modified it doesn't seem we have a regression here.
5 - CanvasDelegate.draw [5] - creating small bitmaps to do low level painting of various toolbar elements
https://crash-stats.mozilla.com/report/index/200bbb54-ca2f-4571-ba1d-074c10190226
All the failed allocation I see in crash reports are for 150KB / 84 KB / 37 KB / 107 KB / 64 KB so very small Bitmaps which again should not be problematic on their own. Also the code related to this hasn't been recently modified it doesn't seem we have a regression here.
6 - IconGenerator.generate [6] - creating a Bitmap for a default favicon
https://crash-stats.mozilla.com/report/index/3d6bddc8-f389-4d51-9dab-d7f310190225
Very small Bitmaps, no recent code changes. Doesn't seem like a regression in the immediately related code.
7 - CombinedHistoryPanel.setUpEmptyViews - sets a drawable as the content of an ImageView
https://crash-stats.mozilla.com/report/index/e2c93678-88bd-4f70-89dc-cdcda0190225
Drawable's xxxhdpi resolution is 360x360 so it's maximum size would be 360x360x4 = 518 KB.
Only used in one place , the crash is from using an Android API. Again, the high memory pressure seems to be already there, probably having other causes.

[1] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#1595
[2] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/tabs/TabsPanelThumbnailView.java#45
[3] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/media/GeckoMediaControlAgent.java#472
[4] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#3429
[5] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/toolbar/CanvasDelegate.java#37
[6] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/icons/loader/IconGenerator.java#70
[7] https://searchfox.org/mozilla-central/rev/b10ae6b7a50d176a813900cbe9dc18c85acd604b/mobile/android/base/java/org/mozilla/gecko/home/CombinedHistoryPanel.java#246

Since I don't see any blatantly incorrect usage and subsampling or using a scaled down version of the Bitmaps is not apropriate for our usecases I think the best we could do is to use the largeHeap[1] attribute to request a higher allocation of heap memory.
Otherwise we could just wrap any Bitmap creation into a try-catch but if the problem is indeed elsewhere this would not really solve anything.

I saw though some big Bitmaps allocations
https://crash-stats.mozilla.com/report/index/f052c0fb-92ae-414d-8cd7-41b2c0190226
https://crash-stats.mozilla.com/report/index/1c6f1503-b787-4b64-bb7d-316cc0190225
https://crash-stats.mozilla.com/report/index/e325d790-354d-4d13-b0ad-84d8f0190225
https://crash-stats.mozilla.com/report/index/2e784da7-fb06-4a0d-8b59-20b3f0190225
https://crash-stats.mozilla.com/report/index/7e64b2d8-0c03-4914-9992-b24a70190225
https://crash-stats.mozilla.com/report/index/e714ecb9-a66f-421e-8b1e-6638b0190225
https://crash-stats.mozilla.com/report/index/65e625d1-8dea-4270-a566-0461c0190225
https://crash-stats.mozilla.com/report/index/bddabb16-ffbc-4289-8c8d-f30880190225
https://crash-stats.mozilla.com/report/index/d150e9f8-fb16-469b-ade2-e39230190225
https://crash-stats.mozilla.com/report/index/d150e9f8-fb16-469b-ade2-e39230190225
inside NotificationClient.add [2] and I think that's possible because we do not actually impose any restrictions for the notification's large icon (which should have a maximum dimension of 256x256 pixels) which we download from a passed in url and for this I will prepare a patch.

[1] https://developer.android.com/guide/topics/manifest/application-element#largeHeap
[2] https://searchfox.org/mozilla-central/rev/00f3836a87b844b5e4bc82f698c559b9966e4be2/mobile/android/base/java/org/mozilla/gecko/notifications/NotificationClient.java#175

There are crash reports for large heap allocations for Bitmaps from the
NotificationClient#add method.
As more of a speculative fix this patch introduces bitmap size constraints for
the largeIcon of the notification this method posts. Previously the app would
happily load any image from the passed in image URL even though the maximum
size the largeIcon can be is 256x256 pixels.

Keywords: checkin-needed

Pushed by nerli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/adc910e55eb6
Apply size restrictions for the largeIcon used in NotificationClient; r=JanH

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

Please request Beta approval on this when you get a chance.

Flags: needinfo?(petru.lingurar)

Given that it's so late in beta maybe we can let this fix ride with 67.

Given that this would possibly fix just a part of the problem, not the entire issue and that we are so late in beta I think we can wait for the next train.
Removing my NI.

Flags: needinfo?(petru.lingurar)
You need to log in before you can comment on or make changes to this bug.