Last Comment Bug 802510 - java.lang.RuntimeException: Buffer not large enough for pixels at android.graphics.Bitmap.copyPixelsFromBuffer(Bitmap.java) especially on Android 4.2
: java.lang.RuntimeException: Buffer not large enough for pixels at android.gra...
Status: VERIFIED FIXED
[native-crash]
: crash, regression, reproducible, topcrash
Product: Firefox for Android
Classification: Client Software
Component: General (show other bugs)
: 19 Branch
: ARM Android
: -- critical with 4 votes (vote)
: Firefox 19
Assigned To: (Back on May31) Kartikaya Gupta (email:kats@mozilla.com)
:
Mentors:
: 811657 811661 811711 812062 812181 812461 812757 812902 (view as bug list)
Depends on:
Blocks: 787765
  Show dependency treegraph
 
Reported: 2012-10-17 01:09 PDT by Scoobidiver (away)
Modified: 2013-12-10 10:01 PST (History)
24 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
+
verified
+
fixed
verified


Attachments
Reset position to zero (1.79 KB, patch)
2012-11-13 17:24 PST, (Back on May31) Kartikaya Gupta (email:kats@mozilla.com)
no flags Details | Diff | Review
Reset position to zero (1.10 KB, patch)
2012-11-13 17:28 PST, (Back on May31) Kartikaya Gupta (email:kats@mozilla.com)
blassey.bugs: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Review

Description Scoobidiver (away) 2012-10-17 01:09:48 PDT
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
Comment 1 Scoobidiver (away) 2012-10-17 09:54:43 PDT
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
Comment 2 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-10-17 10:45:02 PDT
Almost certainly regression from this:

a7702d5a4834	Wes Johnston — Bug 787765
Comment 3 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-10-23 09:58:44 PDT
This will be fixed by the patch on bug 803687.

*** This bug has been marked as a duplicate of bug 803687 ***
Comment 4 Scoobidiver (away) 2012-10-27 00:39:59 PDT
There are still crashes in 19.0a1/20121026 (bp-609eea88-740c-4c8c-8079-ca9da2121027) after the fix of bug 803687.
Comment 5 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-10-29 08:53:19 PDT
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?)
Comment 6 Scoobidiver (away) 2012-11-11 02:32:35 PST
It's #9 top crasher in 19.0a1.
Comment 7 bubbleguuum 2012-11-13 07:56:26 PST
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.
Comment 8 Wesley Johnston (:wesj) 2012-11-13 08:55:10 PST
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.
Comment 9 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-13 09:34:37 PST
(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 bubbleguuum 2012-11-13 09:45:46 PST
(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.
Comment 11 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-13 17:24:55 PST
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()
Comment 12 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-13 17:28:03 PST
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
Comment 13 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-13 17:33:24 PST
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
Comment 14 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-13 17:36:48 PST
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
Comment 15 Aaron Train [:aaronmt] 2012-11-13 19:02:29 PST
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.
Comment 16 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-14 00:34:39 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/250576c9698e
Comment 17 Scoobidiver (away) 2012-11-14 03:37:30 PST
*** Bug 811657 has been marked as a duplicate of this bug. ***
Comment 18 Scoobidiver (away) 2012-11-14 03:37:45 PST
*** Bug 811661 has been marked as a duplicate of this bug. ***
Comment 19 Aaron Train [:aaronmt] 2012-11-14 06:42:39 PST
*** Bug 811711 has been marked as a duplicate of this bug. ***
Comment 20 Ed Morley [:emorley] 2012-11-14 06:51:16 PST
https://hg.mozilla.org/mozilla-central/rev/250576c9698e
Comment 21 Aaron Train [:aaronmt] 2012-11-14 07:14:58 PST
Verified on mozilla-inbound (19); Nexus 7 (Android 4.2)
Comment 22 Lukas Blakk [:lsblakk] use ?needinfo 2012-11-14 07:52:11 PST
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.
Comment 23 bubbleguuum 2012-11-14 08:00:28 PST
(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.
Comment 24 Tyler Downer [:Tyler] 2012-11-14 08:08:03 PST
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.
Comment 25 Lukas Blakk [:lsblakk] use ?needinfo 2012-11-14 08:09:52 PST
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
Comment 26 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-14 08:10:04 PST
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).
Comment 27 dextro 2012-11-14 08:11:07 PST
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.
Comment 28 Scoobidiver (away) 2012-11-14 08:11:57 PST
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.
Comment 29 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-14 08:12:40 PST
(Sorry for the redundancy, adding a comment on an attachment doesn't check for mid-air collisions)
Comment 31 Aaron Train [:aaronmt] 2012-11-14 08:39:55 PST
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.
Comment 32 (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) 2012-11-14 09:32:28 PST
Also I filed bug 811763 for the crash reporter possibly not appearing.
Comment 33 Andy Burns 2012-11-14 13:59:42 PST
(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 Andy Burns 2012-11-14 14:03:29 PST
(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.
Comment 35 Kevin Brosnan [:kbrosnan] 2012-11-14 16:35:14 PST
Verified fixed on Firefox 17 Beta 6 build 2
Comment 36 Aaron Train [:aaronmt] 2012-11-14 20:18:24 PST
*** Bug 812062 has been marked as a duplicate of this bug. ***
Comment 37 Aaron Train [:aaronmt] 2012-11-15 07:44:08 PST
*** Bug 812181 has been marked as a duplicate of this bug. ***
Comment 38 Ekanan Ketunuti 2012-11-16 02:57:15 PST
*** Bug 812461 has been marked as a duplicate of this bug. ***
Comment 39 Ekanan Ketunuti 2012-11-17 05:06:50 PST
*** Bug 812757 has been marked as a duplicate of this bug. ***
Comment 40 Aaron Train [:aaronmt] 2012-11-18 11:44:53 PST
*** Bug 812902 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.