Closed Bug 1163841 Opened 4 years ago Closed 4 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 :: Toolbar, defect, critical)

All
Android
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Firefox 41
Tracking Status
firefox38 + verified
firefox38.0.5 + fixed
firefox39 + fixed
firefox40 + fixed
firefox41 + fixed
relnote-firefox --- 38+
fennec 38+ ---

People

(Reporter: kbrosnan, Assigned: snorp)

References

Details

(Keywords: crash, topcrash-android-armv7)

Crash Data

Attachments

(1 file)

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)
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)
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)
If I disable Android's hardware accelerated drawing, I can reproduce this crash. Patch coming.
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 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+
We could build a 38.0.5beta for Firefox for Android.
(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.
Assignee: nobody → snorp
Status: NEW → ASSIGNED
tracking-fennec: ? → 38+
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?
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: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
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?
Flags: needinfo?(snorp)
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.
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.
(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)
(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 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+
Is this code on 38.0.5? We need to do a mobile build for that release.
Flags: needinfo?(lhenry)
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)
20127 crashes in 14 days on 38.0 and 71 crashes in 14 days on 38.0.1. Good enough for me.
Good for Kevin, good for me :)
Flags: needinfo?(sledru)
Flags: needinfo?(lhenry)
You need to log in before you can comment on or make changes to this bug.