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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Scoobidiver (away)]

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)]

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

[Kartikaya Gupta (email:[e-mail])]

Almost certainly regression from this:

a7702d5a4834	Wes Johnston — Bug 787765

Comment 3

[Kartikaya Gupta (email:[e-mail])]

This will be fixed by the patch on bug 803687.

Comment 4

[Scoobidiver (away)]

There are still crashes in 19.0a1/20121026 (bp-609eea88-740c-4c8c-8079-ca9da2121027) after the fix of bug 803687.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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)]

It's #9 top crasher in 19.0a1.

Comment 7

[bubbleguuum]

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)]

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

[Kartikaya Gupta (email:[e-mail])]

(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]

(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

[Kartikaya Gupta (email:[e-mail])]

Attachment: 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

[Kartikaya Gupta (email:[e-mail])]

Attachment: Reset position to zero

Now without the change to browser.js that got inadvertently included into the first patch

Comment 13

[Kartikaya Gupta (email:[e-mail])]

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

[Kartikaya Gupta (email:[e-mail])]

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]]

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

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/integration/mozilla-inbound/rev/250576c9698e

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/250576c9698e

Comment 21

[Aaron Train [:aaronmt]]

Verified on mozilla-inbound (19); Nexus 7 (Android 4.2)

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

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]

(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 [He/Him]]

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]

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

[Kartikaya Gupta (email:[e-mail])]

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]

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)]

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

[Kartikaya Gupta (email:[e-mail])]

(Sorry for the redundancy, adding a comment on an attachment doesn't check for mid-air collisions)

Comment 30

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 31

[Aaron Train [:aaronmt]]

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

[Kartikaya Gupta (email:[e-mail])]

Also I filed bug 811763 for the crash reporter possibly not appearing.

Comment 33

[Andy Burns]

(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]

(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 [Ex-Mozilla]]

Verified fixed on Firefox 17 Beta 6 build 2