Closed
Bug 1163841
Opened 9 years ago
Closed 9 years ago
crash in org.mozilla.gecko.gfx.GLController$GLControllerException: No available EGL configurations Error 12289 at org.mozilla.gecko.gfx.GLController.AttemptPreallocateEGLSurfaceForCompositor(GLController.java)
Categories
(Firefox for Android Graveyard :: Toolbar, defect)
Tracking
(firefox38+ verified, firefox38.0.5+ fixed, firefox39+ fixed, firefox40+ fixed, firefox41+ fixed, relnote-firefox 38+, fennec38+)
People
(Reporter: kbrosnan, Assigned: snorp)
References
Details
(Keywords: crash, topcrash-android-armv7)
Crash Data
Attachments
(1 file)
6.79 KB,
patch
|
jchen
:
review+
lizzard
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
lmandel
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-a82d710b-e51c-4898-a957-a1ebf2150506. ============================================================= This crash looks odd. There are reports from obviously bogus devices such as innotek GmbH; VirtualBox; x86 Parallels Software International Inc.; Parallels Virtual Platform; x86 samsung; GT-I9100; x86 (Galaxy S2 - should be ARMv7) samsung; GT-I9300; x86 (Galaxy S3 - should be ARMv7) samsung; GT-I9500; x86 (Galaxy S4 - should be ARMv7) samsung; GT-N7100; x86 (Galaxy Note 2 - should be ARMv7) samsung; SAMSUNG-SM-N900A; x86 (Galaxy Note 3 AT&T - should be ARMv7) samsung; SM-G900F; x86 (Galaxy S5 Korea - should be ARMv7) unknown; Android SDK built for x86; x86 VMware, Inc.; VMware Virtual Platform; x86 Xamarin; Nexus 7 (Jelly Bean); x86 (should be ARMv7) Xen; HVM domU; x86 This accounts for about half the crashes. Can we assume that the majority of the ARM crashes are also emulators? I started up an AVD image using Android 5.1 x86 with host GPU acceleration and Firefox started and navigated to a couple websites without issue. The AVD would not start without host GPU.
Flags: needinfo?(snorp)
Reporter | ||
Comment 1•9 years ago
|
||
This is +15% of all crashes in early 38 release data. https://crash-stats.mozilla.com/search/?product=FennecAndroid&version=38.0&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
Flags: needinfo?(nchen)
Flags: needinfo?(mh+mozilla)
Comment 2•9 years ago
|
||
Some of the crashes, like the one mentioned in comment 0, have a native stack trace that doesn't match the java stack trace and indicates something that looks like an OOM. The java stack trace suggests our EGL modules are not loaded. I don't have much knowledge of this part of the java code.
Flags: needinfo?(mh+mozilla)
Assignee | ||
Comment 3•9 years ago
|
||
Yeah, my gut feeling is that bug 1159262 caused this. I'm not sure why we wouldn't have seen this before, but it sounds like some (x86?) devices don't use GL rendering for the UI and we still need to initialize EGL.
Flags: needinfo?(snorp)
Assignee | ||
Comment 4•9 years ago
|
||
If I disable Android's hardware accelerated drawing, I can reproduce this crash. Patch coming.
Assignee | ||
Comment 5•9 years ago
|
||
Attachment #8605291 -
Flags: review?(nchen)
Assignee | ||
Comment 6•9 years ago
|
||
In bug 1159262, we stopped calling eglInitialize() for Android 4.0 and higher. This was to avoid a crash related to eglInitialize(), and the idea was that we didn't need it anyway. It turns out some devices are not using hardware rendering for the Android UI, so EGL is not already initialized for us. This patch changes the behavior to call eglInitialize() on startup unconditionally, but removes the preload hack where we call it in another thread. The idea here is that the preload was causing the eglInitialize() crash on some devices. So, we need to: 1) Verify that this patch fixes this bug (it does for me here) 2) Verify that this patch does not regress bug 1159262
Flags: needinfo?(nchen)
Comment 7•9 years ago
|
||
Comment on attachment 8605291 [details] [diff] [review] Always call eglInitialize(), but kill the preloading hack (which was crashing before) Review of attachment 8605291 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. So we should expect a small startup regression on autophone? ::: mobile/android/base/gfx/GLController.java @@ +176,5 @@ > + // preloading optimization, not something we rely on for anything else. > + // > + // Also note that while calling eglInitialize isn't necessary on Android 4.x > + // (at least Android's HardwareRenderer does it for us already), it is necessary > + // on Android 2.x. Update these comments to say we can't reliably preload EGL and/or skip EGL init?
Attachment #8605291 -
Flags: review?(nchen) → review+
Reporter | ||
Comment 8•9 years ago
|
||
We could build a 38.0.5beta for Firefox for Android.
Updated•9 years ago
|
Comment 9•9 years ago
|
||
(In reply to Kevin Brosnan [:kbrosnan] from comment #8) > We could build a 38.0.5beta for Firefox for Android. I think it would be good to build a 38.0.5 beta as well as a 38.0.1 release with this patch, the beta possibly together with the regular desktop beta 2.
Updated•9 years ago
|
Assignee: nobody → snorp
Status: NEW → ASSIGNED
tracking-fennec: ? → 38+
Assignee | ||
Comment 10•9 years ago
|
||
Comment on attachment 8605291 [details] [diff] [review] Always call eglInitialize(), but kill the preloading hack (which was crashing before) Approval Request Comment [Feature/regressing bug #]: bug 1159262 [User impact if declined]: crashes on some unknown subset of devices [Describe test coverage new/current, TreeHerder]: local only, building/running on inbound now [Risks and why]: low, but could regress the fix for bug 1159262. Worst case is that we end up shipping basically the same behavior we had for 37. [String/UUID change made/needed]: none
Attachment #8605291 -
Flags: approval-mozilla-release?
Attachment #8605291 -
Flags: approval-mozilla-beta?
Attachment #8605291 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 11•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a31da903e8ed
Comment 12•9 years ago
|
||
Comment on attachment 8605291 [details] [diff] [review] Always call eglInitialize(), but kill the preloading hack (which was crashing before) We're going to take this fix for 38.0.1 so that we can gtb now. snorp is working on verifying the fix and we are only going to release after the fix is verified. This should land on the Firefox 38 relbranch but NOT on m-r (or anywhere else other than m-c) until it is verified.
Attachment #8605291 -
Flags: approval-mozilla-release? → approval-mozilla-release+
GECKO380_2015050320_RELBRANCH: https://hg.mozilla.org/releases/mozilla-release/rev/65cecd7df572 Hope that's the right relbranch for this.
https://hg.mozilla.org/mozilla-central/rev/a31da903e8ed
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
Comment 15•9 years ago
|
||
Release Note Request (optional, but appreciated) [Why is this notable]: Topcrash [Suggested wording]: Fixed: Start-up crash on devices for which Firefox does not support Android hardware acceleration [Links (documentation, blog post, etc)]: snorp - Can you please confirm that this release note is correct? Do you have any suggested changes?
Comment 16•9 years ago
|
||
Note for QE: snorp is verifying that this fix doesn't regress bug 1159262. He doesn't have a device that reproduces the crash but says "I am 100% sure it fixes the release crash". If you can reproduce the crash on device it will be useful to verify the fix.
Comment 17•9 years ago
|
||
ran 6 tests with nexus 5 and nexus 7 devices. Results here: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=fb6329699801&exclusion_profile=false&filter-searchStr=autophone Note the t (s1s2) and w (webapp) tests are the relevant tests. 3 failures to get measurements but I didn't see any tombstones or crashes.
Assignee | ||
Comment 18•9 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #15) > Release Note Request (optional, but appreciated) > [Why is this notable]: Topcrash > [Suggested wording]: Fixed: Start-up crash on devices for which Firefox does > not support Android hardware acceleration > [Links (documentation, blog post, etc)]: > > snorp - Can you please confirm that this release note is correct? Do you > have any suggested changes? Looks good to me
Flags: needinfo?(snorp)
Assignee | ||
Comment 19•9 years ago
|
||
(In reply to Bob Clary [:bc:] from comment #17) > ran 6 tests with nexus 5 and nexus 7 devices. Results here: > > https://treeherder.mozilla.org/#/jobs?repo=mozilla- > inbound&revision=fb6329699801&exclusion_profile=false&filter- > searchStr=autophone > > Note the t (s1s2) and w (webapp) tests are the relevant tests. 3 failures to > get measurements but I didn't see any tombstones or crashes. Thanks a lot, that looks pretty good overall.
Comment 20•9 years ago
|
||
Comment on attachment 8605291 [details] [diff] [review] Always call eglInitialize(), but kill the preloading hack (which was crashing before) Approved for uplift to aurora (40) and beta (39) to see if this mitigates crashes.
Attachment #8605291 -
Flags: approval-mozilla-beta?
Attachment #8605291 -
Flags: approval-mozilla-beta+
Attachment #8605291 -
Flags: approval-mozilla-aurora?
Attachment #8605291 -
Flags: approval-mozilla-aurora+
Reporter | ||
Comment 23•9 years ago
|
||
Is this code on 38.0.5? We need to do a mobile build for that release.
Flags: needinfo?(lhenry)
Comment 24•9 years ago
|
||
Kevin, it should probably have an uplift request to go to mozilla-release. Sylvestre I'm cc-ing you in. It doesn't look like we have real verification for this yet.
Flags: needinfo?(sledru)
Reporter | ||
Comment 25•9 years ago
|
||
20127 crashes in 14 days on 38.0 and 71 crashes in 14 days on 38.0.1. Good enough for me.
Updated•9 years ago
|
Flags: needinfo?(lhenry)
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•