The default bug view has changed. See this FAQ.

java.lang.RuntimeException: Buffer not large enough for pixels at android.graphics.Bitmap.copyPixelsFromBuffer(Bitmap.java) especially on Android 4.2

VERIFIED FIXED in Firefox 17

Status

()

Firefox for Android
General
--
critical
VERIFIED FIXED
5 years ago
8 months ago

People

(Reporter: Scoobidiver (away), Assigned: kats)

Tracking

(4 keywords)

19 Branch
Firefox 19
ARM
Android
crash, regression, reproducible, topcrash
Points:
---

Firefox Tracking Flags

(firefox16 affected, firefox17+ verified, firefox18+ fixed, firefox19 verified)

Details

(Whiteboard: [native-crash], crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
There are three crashes, one in 17.0b1 and two in 19.0a1/20121016 from two different users. Here is a crash report: bp-12b82731-3da0-45e2-9ebb-fc8ef2121017.

java.lang.RuntimeException: Buffer not large enough for pixels
	at android.graphics.Bitmap.copyPixelsFromBuffer(Bitmap.java:409)
	at org.mozilla.gecko.GeckoApp.handleThumbnailData(GeckoApp.java:737)
	at org.mozilla.gecko.ScreenshotHandler$2.run(ScreenshotHandler.java:370)
	at android.os.Handler.handleCallback(Handler.java:615)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:137)
	at org.mozilla.gecko.util.GeckoBackgroundThread.run(GeckoBackgroundThread.java:31)

More reports at:
https://crash-stats.mozilla.com/report/list?signature=java.lang.RuntimeException%3A+Buffer+not+large+enough+for+pixels+at+android.graphics.Bitmap.copyPixelsFromBuffer%28Bitmap.java%29
(Reporter)

Updated

5 years ago
Component: Graphics, Panning and Zooming → General
(Reporter)

Comment 1

5 years ago
Four crashes from four different users mean it's a regression. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=942ed5747b63&tochange=8f145599e4bf
Keywords: regression
Version: Trunk → Firefox 19
Almost certainly regression from this:

a7702d5a4834	Wes Johnston — Bug 787765
(Reporter)

Updated

5 years ago
Blocks: 787765
This will be fixed by the patch on bug 803687.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 803687
(Reporter)

Comment 4

5 years ago
There are still crashes in 19.0a1/20121026 (bp-609eea88-740c-4c8c-8079-ca9da2121027) after the fix of bug 803687.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
From code inspection, I hypothesize this is happening because AboutHomeContent.java calls setThumbnailWidth and changes the thumbnail size. The next thumbnail generated will have the new size but the existing bitmap objects in the Tab instances will have the old size, and this results in the exception when the ScreenshotHandler tries to set the thumbnail.

:wesj, when does the TopSitesGridView.onMeasure run? (Or more specifically, under what conditions will it cause the thumbnail width to change?)
Flags: needinfo?(wjohnston)
(Reporter)

Comment 6

4 years ago
It's #9 top crasher in 19.0a1.
tracking-fennec: --- → ?
status-firefox18: --- → unaffected
status-firefox19: --- → affected
tracking-firefox19: --- → ?
Keywords: topcrash

Comment 7

4 years ago
I've updated my Nexus 7 from 4.1.2 to the new official 4.2 update and this crash happens within 1 or 2 mins of browsing. Another user reported the same issue.
It never happened on Android 4.1.2.

It happened with 16.0.2 and 17 (beta) available on Google Play.

This makes Firefox unusuable.

Looks like something in 4.2 make this bug always happen now.
I suspect there's a race somewhere where we're changing the thumbnail size between the time its requested and received. I'll try to get to this tomorrow.
Flags: needinfo?(wjohnston)
(In reply to bubbleguuum from comment #7)
> I've updated my Nexus 7 from 4.1.2 to the new official 4.2 update and this
> crash happens within 1 or 2 mins of browsing. Another user reported the same
> issue.
> It never happened on Android 4.1.2.
> 
> It happened with 16.0.2 and 17 (beta) available on Google Play.

Do you have a link to a crash report for this? The code that I suspect is causing this crash is only in FF 19, so I wonder if the crashes you're seeing on 16 and 17 are slightly different.

Comment 10

4 years ago
(In reply to Kartikaya Gupta (:kats) from comment #9)
> (In reply to bubbleguuum from comment #7)
> > I've updated my Nexus 7 from 4.1.2 to the new official 4.2 update and this
> > crash happens within 1 or 2 mins of browsing. Another user reported the same
> > issue.
> > It never happened on Android 4.1.2.
> > 
> > It happened with 16.0.2 and 17 (beta) available on Google Play.
> 
> Do you have a link to a crash report for this? The code that I suspect is
> causing this crash is only in FF 19, so I wonder if the crashes you're
> seeing on 16 and 17 are slightly different.

When I stumbled on that crash I did not submit a new crash report since it seems to be this one. It happens for me all the time, after browsing a few pages.

Here's the stack trace (v16.0.2 running on Nexus 7, Android 4.2):

11-13 16:33:05.503: E/GeckoAppShell(9030): >>> REPORTING UNCAUGHT EXCEPTION FROM THREAD 413 ("GeckoBackgroundThread")
11-13 16:33:05.503: E/GeckoAppShell(9030): java.lang.RuntimeException: Buffer not large enough for pixels
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at android.graphics.Bitmap.copyPixelsFromBuffer(Bitmap.java:417)
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at org.mozilla.gecko.GeckoApp.handleThumbnailData(GeckoApp.java:609)
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at org.mozilla.gecko.ScreenshotHandler$1.run(GeckoAppShell.java:2578)
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at android.os.Handler.handleCallback(Handler.java:725)
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at android.os.Handler.dispatchMessage(Handler.java:92)
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at android.os.Looper.loop(Looper.java:137)
11-13 16:33:05.503: E/GeckoAppShell(9030): 	at org.mozilla.gecko.GeckoBackgroundThread.run(GeckoBackgroundThread.java:31)
11-13 16:33:06.603: D/Zygote(126): Process 9030 terminated by signal (11)
11-13 16:33:06.633: I/ActivityManager(486): Process org.mozilla.firefox (pid 9030) has died.

If you find a fix, I can test any APK if needed.
Created attachment 681301 [details] [diff] [review]
Reset position to zero

I'm able to reproduce this on a device with 4.2, although now that I've debugged it I don't understand why it just doesn't happen all the time. I guess maybe the android implementation of the java.nio.ReadWriteDirectByteBuffer could have changed. Or the implementation of Bitmap.copyPixelsFromBuffer could have changed. Anyway, the problem is that the position() of the buffer we pass in to copyPixelsFromBuffer is already at the limit of the buffer, so there's no more pixels that can be read from that point on. We should be resetting the position to 0 before making that call. Without this patch Fennec consistently crashes after the second page load because at that point the buffer.position() is the same as buffer.limit()
Assignee: nobody → bugmail.mozilla
Attachment #681301 - Flags: review?(blassey.bugs)
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: unaffected → affected
Created attachment 681303 [details] [diff] [review]
Reset position to zero

Now without the change to browser.js that got inadvertently included into the first patch
Attachment #681301 - Attachment is obsolete: true
Attachment #681301 - Flags: review?(blassey.bugs)
Attachment #681303 - Flags: review?(blassey.bugs)
Comment on attachment 681303 [details] [diff] [review]
Reset position to zero

Preemptively requesting uplift to get this on the radar for aurora/beta

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: fennec crashes on the second page load in some cases
Testing completed (on m-c, etc.): locally
Risk to taking this patch (and alternatives if risky): low-risk, not much that can go wrong here. android only
String or UUID changes made by this patch: none
Attachment #681303 - Flags: approval-mozilla-beta?
Attachment #681303 - Flags: approval-mozilla-aurora?
The android issue at [1] might explain why this only happens on some devices or versions.

[1] http://code.google.com/p/android/issues/detail?id=32588
This is causing a slew of negative reviews on Google Play from Nexus 7 owners who just got a 4.2 update and are experiencing constant crashes.

Recommending this for 17.
Attachment #681303 - Flags: review?(blassey.bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/250576c9698e
(Reporter)

Updated

4 years ago
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
(Reporter)

Updated

4 years ago
Duplicate of this bug: 811657
(Reporter)

Updated

4 years ago
Duplicate of this bug: 811661
(Reporter)

Updated

4 years ago
Summary: java.lang.RuntimeException: Buffer not large enough for pixels at android.graphics.Bitmap.copyPixelsFromBuffer(Bitmap.java) → java.lang.RuntimeException: Buffer not large enough for pixels at android.graphics.Bitmap.copyPixelsFromBuffer(Bitmap.java) especially on Android 4.2

Updated

4 years ago
Duplicate of this bug: 811711

Updated

4 years ago
Keywords: reproducible
https://hg.mozilla.org/mozilla-central/rev/250576c9698e
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
Verified on mozilla-inbound (19); Nexus 7 (Android 4.2)
Status: RESOLVED → VERIFIED
status-firefox19: affected → verified
This is only a topcrasher on Nightly (19) so we can uplift to 18 but we've already built our final beta of 17 and without significant volume of crashes for this on 17 there's no reason to take the risk of cramming this in without testing between final beta and release.
status-firefox17: affected → wontfix
tracking-firefox17: ? → -
tracking-firefox18: ? → +
tracking-firefox19: ? → ---
Attachment #681303 - Flags: approval-mozilla-beta?
Attachment #681303 - Flags: approval-mozilla-beta-
Attachment #681303 - Flags: approval-mozilla-aurora?
Attachment #681303 - Flags: approval-mozilla-aurora+

Comment 23

4 years ago
(In reply to Lukas Blakk [:lsblakk] from comment #22)
> This is only a topcrasher on Nightly (19) so we can uplift to 18 but we've
> already built our final beta of 17 and without significant volume of crashes
> for this on 17 there's no reason to take the risk of cramming this in
> without testing between final beta and release.

It is a top crasher in 16.0.2 for people running Android 4.2 making Firefox totally unusuable. Have a look at the Google Play comments since yesterday.
https://play.google.com/store/apps/details?id=org.mozilla.firefox&reviewId=bGc6QU9xcFRPR0hZWDBQbzhuOEtrb29qaWxzWEEtdU1QdXVWTWt2Xy1KeFdrMXl3SXJ5UWRxS09qUmxaY01uOUJxdkZFdU5wNWhKSnV5dDVtWUZGUi1RMXc

If possible I'd like to see this get into 17. This mainly affects users on 4.2, which has only been released since yesterday. All new nexus devices and most older ones will be updated to 4.2 before we release 18, which means that we won't be usable on these devices for 6 weeks. I'd like to avoid that pain if at all possible.
In light of the seriousness of this crash on the newly-released 4.2, we'll uplift to beta and respin just the mobile 17.0b6
status-firefox17: wontfix → affected
tracking-firefox17: - → +
Comment on attachment 681303 [details] [diff] [review]
Reset position to zero

Re-requesting beta. Android 4.2 only came out yesterday so it hasn't had time to reflect in the crash reports, but over the next 6 weeks lots of people will be using it and FF will be unusable for them. In fact I think it makes sense to push out a new beta with this fix or even a chemspill so that our users who upgrade to 4.2 don't give up in disgust and switch to chrome over the next week before the next release(s).
Attachment #681303 - Flags: approval-mozilla-beta- → approval-mozilla-beta?
Attachment #681303 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment 27

4 years ago
I confirm that it crashes virtually every time Firefox is used under android 4.2 on a Nexus 7. I haven't managed to do a full browsing session using firefox yet since 4.2 came out. I've resorted to using chrome since Firefox is unusable.

It's also interesting to note that Firefox hasn't prompted me to submit a crash report after these crashes.
(Reporter)

Comment 28

4 years ago
In addition to comment 23, crashes on Android 4.2 are not submitted to Socorro (look for 4.2 in https://crash-analysis.mozilla.com/rkaiser/2012-11-13/2012-11-13.fennecandroid.release.16.0.devices.html and in dupes with no crash ID) so it's an invisible top crasher in 16.0.2.
(Sorry for the redundancy, adding a comment on an attachment doesn't check for mid-air collisions)
aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/7e899c1cfcae

beta:
http://hg.mozilla.org/releases/mozilla-beta/rev/9155f086562a

beta relbranch:
http://hg.mozilla.org/releases/mozilla-beta/rev/eba2b989092a
status-firefox17: affected → fixed
status-firefox18: affected → fixed
Those following along, this will be fixed in the next available in Firefox Beta update on Google Play, and aiming for Firefox 17 when released.
Also I filed bug 811763 for the crash reporter possibly not appearing.

Comment 33

4 years ago
(In reply to Lukas Blakk [:lsblakk] from comment #22)

> This is only a topcrasher on Nightly (19) so we can uplift to 18

By my estimation 18 won't be released until approx 31st December? 

The Nexus7 i the biggest selling Android tablet to date, 4.2 was only released yesterday, so it's either the lucky few or those who manually upgraded that have it, yet the Play store reviews are already plagued by one star ****/rubbish/removed user comments.

I'd really recommend reconsidering the fix for 17 for android, or you're anding market share back to Chrome.

Comment 34

4 years ago
(In reply to Lukas Blakk [:lsblakk] from comment #25)#

> In light of the seriousness of this crash on the newly-released 4.2, we'll
> uplift to beta and respin just the mobile 17.0b6

I should have read more bugmail before responding, good decision to slip it into 17 I think.
status-firefox17: fixed → verified
Verified fixed on Firefox 17 Beta 6 build 2

Updated

4 years ago
Duplicate of this bug: 812062

Updated

4 years ago
Duplicate of this bug: 812181

Updated

4 years ago
Duplicate of this bug: 812461

Updated

4 years ago
Duplicate of this bug: 812757

Updated

4 years ago
Duplicate of this bug: 812902
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.