Closed Bug 838603 Opened 10 years ago Closed 10 years ago

Startup crash spike on Android with abort message: "OpenGL-accelerated layers are a hard requirement on this platform [...]"

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
blocker

Tracking

(firefox18 verified, firefox19+ verified, firefox20+ verified, firefox21+ verified)

VERIFIED FIXED
Firefox 21
Tracking Status
firefox18 --- verified
firefox19 + verified
firefox20 + verified
firefox21 + verified

People

(Reporter: kairo, Assigned: bjacob)

References

(Depends on 1 open bug)

Details

(Keywords: crash, Whiteboard: [native-crash][startupcrash][str in comment 28])

Crash Data

Attachments

(1 file)

"OpenGL-accelerated layers are a hard requirement on this platform [...]" aborts on startup suddenly HUGELY exploded in yesterday's data, across all branches (including 18 release!), was that something from us (some blocklisting stuff maybe?) or an update shipped to a larger collection of devices (I've seen this across Samsung, HTC, and other devices when looking through a number of reports) that makes us fail to enable OpenGL layers?

The list of affected devices is roughly the first one in this report (we don't have per-abort-message stats, so I'm using the most-common signature those have, i.e. "mozalloc_abort"): https://crash-analysis.mozilla.com/rkaiser/2013-02-05/2013-02-05.fennecandroid.release.18.0.devices.html#sigs

Right now I suspect bug 824118 as the most likely cause.
This has hugely made our startup crash percentage worse, probably is by far the topcrash on all channels for Android in yesterday's data, and looks like it made Firefox for Android unusable on a range of devices where it worked before.

We may have blocked OpenGL layers completely instead of blocking libstagefright usage only.
Blocks: 824118
tracking-fennec: --- → ?
Severity: normal → critical
Crash Signature: [@ mozalloc_abort] [@ mozalloc_abort | pthread_mutex_unlock] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5 | png_get_user_transform_ptr] [@ mozalloc_abort | __sread] [@ mozalloc_abort(char cons…
Keywords: crash
Whiteboard: [native-crash][startupcrash]
Crash Signature: [@ mozalloc_abort] [@ mozalloc_abort | pthread_mutex_unlock] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5 | png_get_user_transform_ptr] [@ mozalloc_abort | __sread] [@ mozalloc_abort(char cons… → [@ mozalloc_abort(char const*) | NS_DebugBreak_P | nsBaseWidget::ComputeShouldAccelerate(bool)] [@ mozalloc_abort] [@ mozalloc_abort | pthread_mutex_unlock] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5] [@ mozalloc_abort | __swrite | libxul.so@0…
Whiteboard: [native-crash][startupcrash] → [native-crash]
Whiteboard: [native-crash] → [native-crash][startupcrash]
How can blocklist.xml be updated with startup crashes?
Flags: needinfo?(bjacob)
So, I just went through a number of those crashes, and it doesn't look like the hardware fields actually align very much with those blocks. That said, as we don't have any better clue and those blocks haven't been QAed, it's good we rolled them back to possibly find out if they are involved. But unfortunately, it's not clear to me that they actually caused this. We might still not have solved the problems.
(In reply to Scoobidiver from comment #2)
> How can blocklist.xml be updated with startup crashes?

Sorry, I don't understand the question?

---

Re: comment 0: OK, point taken, assuming that bug 824118 is indeed what regressed this, this is terrible indeed and a good reason to be paranoid with the downloadable blocklist.

But how can a STAGEFRIGHT blacklist have ended up blocking OpenGL layers?
Flags: needinfo?(bjacob)
(In reply to Scoobidiver from comment #2)
> How can blocklist.xml be updated with startup crashes?

It can't. If affected users have 100% reliable startup crashes, and if the blocklist is indeed the cause, the only solution to the problem is to reset the profile.
Severity: critical → blocker
(In reply to Scoobidiver from comment #2)
> How can blocklist.xml be updated with startup crashes?

Once we have a startup crash, those people only can get a different blocklist if they uninstall, including deleting the profile (I think Android probably does that but other probably know better), and then reinstall - or if they kill the blocklist.xml from their profile, but usually they don't have access to that on Android, unless the device is rooted.


So, as another clue if the blocklists are related to this, I looked at the timing. The comment that the bug 824118 blocks have been pushed was made at 2013-02-04 09:42:16 PST, adding 8h, that's between 17:00 and 18:00 UTC on the 4th. Installations only check for a blocklist update once a day, so it takes some time to bubble up into builds, but the remaining 6h in the UTC day should have some effect still.
First I checked overall volume of the crashes in UTC days. The main signature, mozalloc_abort, had 80-110 crashes per million ADI between 2013-01-26 and 2013-02-03, then was up to 137 on the 4th and 1320 yesterday. So we definitely see a bit of impact of the 4th and way more on the 5th.
Then, I looked at the raw lists of incoming crashes. We see that from 19:00 to midnight (UTC) on the 4th, we were slowly but surely rising in frequency of those crashes, esp. compare to the levels of the 3rd.

This all seems to coincide very well with the blocklist pushes. Still hard evidence, but still points to the blocklist changes as a probably cause.
To fix the startup crash issue, we could (assuming that there is a way to do that) ship a preference update:

Setting layers.acceleration.force-enabled = true will prevent this assertion from being hit.

How do we ship a preference update like that?
This is a preference-only no-code change. Is there a reasonable way to ship it?
Attachment #710782 - Flags: review?(blassey.bugs)
Comment on attachment 710782 [details] [diff] [review]
force-enable GL layers on Android: would remove the startup crash, even for users who already have the bad blocklist.xml

Review of attachment 710782 [details] [diff] [review]:
-----------------------------------------------------------------

As I understand it, users that actually don't have hw accell support will still crash, just in a different place (actual crash as opposed to an abort). If that's correct, then r=blassey. If not, please explain and re-request review
Attachment #710782 - Flags: review?(blassey.bugs) → review+
That's correct, as we don't have a non-GL-layers fallback on Android.

This assertion was supposed to make these crashes easy to identify, but 1) in the face of fragile blacklisting infrastructure, and the fact that blacklisting GL layers on Android means a startup crash, it's too risky for us to have; and 2) removing it seems needed to allow the users who already have this startup crash from recovering.
Given the unusual circumstances, should I land this and request approval in the usual way or are we going to take a shortcut?
Will Firefox be updated with startup crashes?

See https://support.mozilla.org/questions/949479 for how to solve it. Does clearing application data delete blocklist.xml?

(In reply to Benoit Jacob [:bjacob] from comment #11)
> Given the unusual circumstances, should I land this and request approval in
> the usual way or are we going to take a shortcut?
Shortcuts induced this bug.
Are we certain this crash occurs 100% of the time for affected users? Can we reproduce on staging and verify the fix before landing on branches?

I've already noted that I'm surprised we haven't seen any negative feedback in Play reviews from this already.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e65517972de2
Assignee: nobody → bjacob
Whiteboard: [native-crash][startupcrash] → [native-crash][startupcrash][leave open]
Target Milestone: --- → Firefox 21
Comment on attachment 710782 [details] [diff] [review]
force-enable GL layers on Android: would remove the startup crash, even for users who already have the bad blocklist.xml

[Approval Request Comment]
Bug caused by (feature/regressing bug #): TBD -- probably 824118
User impact if declined: startup crash; nontrivial to recover for users who already got the bad blocklist update
Testing completed (on m-c, etc.): m-i
Risk to taking this patch (and alternatives if risky): not risky (We don't run without GL layers on Android anyways)
String or UUID changes made by this patch: none
Attachment #710782 - Flags: approval-mozilla-release?
Attachment #710782 - Flags: approval-mozilla-esr17?
Attachment #710782 - Flags: approval-mozilla-beta?
Attachment #710782 - Flags: approval-mozilla-aurora?
(In reply to Scoobidiver from comment #12)
> Will Firefox be updated with startup crashes?

Yes, through the Play Store (the default update service for Beta/Release)
I've reproduced on my Galaxy Tab 10.1 (Android 3.1) using Fx19 Beta 4 by merely just turning on the tab and launching.
(In reply to Aaron Train [:aaronmt] from comment #17)
> I've reproduced on my Galaxy Tab 10.1 (Android 3.1) using Fx19 Beta 4 by
> merely just turning on the tab and launching.

Crashes 100% of the time afterwards?
(Aaron lent me his device). Yes, crashes 100% of the time afterwards.
(In reply to Benoit Jacob [:bjacob] from comment #19)
> (Aaron lent me his device). Yes, crashes 100% of the time afterwards.

Is a build available to verify the fix?
(In reply to Alex Keybl [:akeybl] from comment #20)
> Is a build available to verify the fix?

This one from TBPL should have it:
http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1360176390/fennec-21.0a1.en-US.android-arm.apk
Here's some numbers on how many installations this seems to affect (counting different installation times as reported in crashes):

date       | crashes | installations 
-----------+---------+---------------
2013-02-03 |     518 |           229
2013-02-04 |     922 |           380
2013-02-05 |    8109 |          2996
2013-02-06 |    9542 |          3970


For reference, I used queries like this:

SELECT COUNT(*) as crashes,COUNT(DISTINCT client_crash_date - install_age  * interval '1 second') as installations FROM reports WHERE version='18.0' AND product='FennecAndroid' AND app_notes LIKE '%OpenGL-accelerated layers%' AND utc_day_is(date_processed, '2013-02-06');
Oh, and note that the UTC day for 2013-02-06 isn't complete, so those numbers will still rise.
The test to verify the fix must be done with the seven blocklist entries (patch of blocklist.xml).
Ugh, this is way worse on older versions (that have fewer users as well!), see e.g. this table for just today:

SELECT version,COUNT(*) as crashes,COUNT(DISTINCT client_crash_date - install_age  * interval '1 second') as installations FROM reports WHERE product='FennecAndroid' AND app_notes LIKE '%OpenGL-accelerated layers%' AND utc_day_is(date_processed, '2013-02-06') GROUP BY version;
 version | crashes | installations 
---------+---------+---------------
 16.0    |    6476 |          2341
 16.0.1  |   28933 |         10293
 16.0.2  |   51235 |         18969
 16.0a1  |       7 |             3
 16.0a2  |     161 |            52
 17.0    |    2676 |          1002
 17.0a1  |      15 |             5
 17.0a2  |      27 |            11
 18.0    |    9634 |          4010
 18.0a1  |      39 |            10
 18.0a2  |      89 |            34
 19.0    |     588 |           232
 19.0a1  |      22 |             8
 20.0a2  |      16 |             5
 21.0a1  |      29 |             8

So, let's redo the table from comment #22 across all versions (of the native-UI builds for Android) and not just 18.0 (just leaving out the version='18.0' in the queries):

date       | crashes | installations 
-----------+---------+---------------
2013-02-03 |     652 |           282
2013-02-04 |   11582 |          4008
2013-02-05 |  108484 |         35181
2013-02-06 |  100275 |         37012

As a comparison, here's all crashes and installations across all versions (of native-UI for Android) for today:

breakpad=> SELECT COUNT(*) as crashes,COUNT(DISTINCT client_crash_date - install_age  * interval '1 second') as installations FROM reports WHERE product='FennecAndroid' AND utc_day_is(date_processed, '2013-02-06');
 crashes | installations 
---------+---------------
  203966 |         87146
(1 row)
I have started a SUMO article for this issue at:
https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix/revision/36251

Note that this article is a very simple placeholder for now and is not yet live. Which means you won't be able to see the article unless you have SUMO reviewer privileges.
Depends on: 838845
(In reply to Roland Tanglao :rolandtanglao from comment #26)
> I have started a SUMO article for this issue at:
> https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix/
> revision/36251
> 
> Note that this article is a very simple placeholder for now and is not yet
> live. Which means you won't be able to see the article unless you have SUMO
> reviewer privileges.

Hi Roland, thanks for throwing this together. As a heads up, we don't expect "OpenGL-accelerated layers are a hard requirement on this platform" to show up in the crash. The only way we can identify this crash specifically is by when it started occurring (since 2/4).
OK, so this is a multi-part comment:
 1. actual steps to reproduce on any android device
 2. verification that this patch fixes the crash on affected devices
 3. partial explanation of this bug

*** 1. actual steps to reproduce on any android device ***

The key is that this only reproduces with a _profile_ from an earlier version of Fennec. As we suspected the Android H264 blacklisting code (bug 806369), I took the last nightly before it (November 1):

$ wget http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012/11/2012-11-01-03-07-05-mozilla-central-android/fennec-19.0a1.multi.android-arm.apk

I uninstall my Fennec (nightly) to start with a fresh profile,

$ adb uninstall org.mozilla.fennec

And install this old build:

$ adb install -r fennec-19.0a1.multi.android-arm.apk

Now I follow the standard steps to get the bad blocklist at
  https://wiki.mozilla.org/Blocklisting/Testing#Testing_on_Android
I.e. set replace addons.mozilla.org by addons-dev.mozilla.org in the blocklist url, and set the refresh interval to 10 sec, and reset other *blocklist* prefs, wait a bit, quit and restart fennec twice.

You should now have the startup crash. You verify that it's the right crash by using adb logcat:

$ adb logcat 2>&1 | grep OpenGL
I/Gecko   ( 4039): ###!!! ABORT: OpenGL-accelerated layers are a hard requirement on this platform. Cannot continue without support for them.: file ../../../widget/xpwidgets/nsBaseWidget.cpp, line 829

Now upgrade to the latest Nightly, which still doesn't have the present fix (as of today) to verify it still reproduces:

$ wget http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-02-06-03-10-27-mozilla-central-android/fennec-21.0a1.multi.android-arm.apk

Upgrade while keeping your profile:

$ adb install -r fennec-21.0a1.multi.android-arm.apk

--> still reproduces.



*** 2. verification that this patch fixes the crash on affected devices ***

Get the inbound build that should not crash:

$ wget http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1360176390/fennec-21.0a1.en-US.android-arm.apk

Upgrade while keeping your profile:

$ adb install -r fennec-21.0a1.en-US.android-arm.apk

---> does not crash

---> present fix VERIFIED


*** 3. partial explanation of this bug ***

I don't yet have an explanation for this bug on versions >= 17, but here is an explanation for why it's so much more crashy on version 16. 

The c++ code there for STAGEFRIGHT blacklisting, bug 806369, was backported to versions >= 17 but not 16.

What this means is that on version 16, STAGEFRIGHT is not known, as a feature name, to the blacklisting code.

Now this is where GfxInfo badness kicks in. Here is the code that handles feature names in the XML and maps them to the symbolic constants used in GfxInfo:

http://hg.mozilla.org/mozilla-central/file/325397090d12/widget/xpwidgets/GfxInfoBase.cpp#l257

You can see that when it doesn't recognize the symbolic constant, it returns 0.

What could go wrong?

Zero is actually interpreted as "all features":

http://hg.mozilla.org/mozilla-central/file/325397090d12/widget/xpwidgets/GfxDriverInfo.cpp#l11

And that means that our blacklisting code, when it sees a blocklist rule with a feature name that it doesn't recognize, interpretes it at "all features".

That would explain why a STAGEFRIGHT blocklist rule is interpreted by firefox 16 as blocking all features.

That explains why we get so much more crashes with firefox 16. It doesn't seem to explain though why fennec versions >= 17 still have crashes.
Comment on attachment 710782 [details] [diff] [review]
force-enable GL layers on Android: would remove the startup crash, even for users who already have the bad blocklist.xml

Please land to all branches. For mozilla-release, please land to both tip and GECKO1802_2013020109_RELBRANCH.
Attachment #710782 - Flags: approval-mozilla-release?
Attachment #710782 - Flags: approval-mozilla-release+
Attachment #710782 - Flags: approval-mozilla-esr17?
Attachment #710782 - Flags: approval-mozilla-esr17-
Attachment #710782 - Flags: approval-mozilla-beta?
Attachment #710782 - Flags: approval-mozilla-beta+
Attachment #710782 - Flags: approval-mozilla-aurora?
Attachment #710782 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/a903b918e169
https://hg.mozilla.org/releases/mozilla-beta/rev/0d42c11c4220
https://hg.mozilla.org/releases/mozilla-release/rev/912b9ffcbaad

Out of curiosity why no ESR? If they upgraded from ESR10, they would presumably be affected as well? (Maybe I didn't look closely enough into KaiRo's numbers)
(In reply to Benoit Jacob [:bjacob] from comment #30)
> Out of curiosity why no ESR?

We have no ESR for native-UI Android (and we only used it for XUL as a workaround while we didn't have tablet support in native UI).
Whiteboard: [native-crash][startupcrash][leave open] → [native-crash][startupcrash][leave open][str in comment 28]
The article is live with the edits suggested by Alex Keybl, Michael Verdi and Michelle Luna. Thanks!

Michelle is going to add it to the Hot issues in SUMO.

https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix
Here is some more information to help QA this.

The fix here is just force-enabling GL layers. These were a hard requirement anyways for Fennec. The difference is that before, we were crashing consistently with this assertion, and now, on a device that actually couldn't support GL layers, I'm not sure actually where we would be crashing, but I expect we'd be crashing shortly afterwards with no user-visible difference.

So this is the only area where I could be concerned about possible regressions: what actually happens now on a device that doesn't support OpenGL layers i.e. any device without OpenGL ES 2 support? See bug 778175 which is specifically about these devices. An example is the HTC Wildfire / Buzz.
(In reply to Benoit Jacob [:bjacob] from comment #33)
> Here is some more information to help QA this.
> 
> The fix here is just force-enabling GL layers. These were a hard requirement
> anyways for Fennec. The difference is that before, we were crashing
> consistently with this assertion, and now, on a device that actually
> couldn't support GL layers, I'm not sure actually where we would be
> crashing, but I expect we'd be crashing shortly afterwards with no
> user-visible difference.
> 
> So this is the only area where I could be concerned about possible
> regressions: what actually happens now on a device that doesn't support
> OpenGL layers i.e. any device without OpenGL ES 2 support? See bug 778175
> which is specifically about these devices. An example is the HTC Wildfire /
> Buzz.

Helpful, thanks.   so if i'm reading that we already dont support phones that are incompatible with OpenGL ES 2.0, i'm inclined to think nothing new should break thats not already known today.   If nothing else, then we can focus on testing the startup path as originally specc'd for staged blocklisted devices.
Thus far verifying Benoit's steps and fix works for me (with the builds he posted) on: LGE Nexus 4 (Android 4.2), Samsung Galaxy Note II (Android 4.1), Samsung Galaxy Nexus (Android 4.2), Samsung Galaxy SII (Android 4.0.4); Asus Transformer Prime (TF201, Android 4.0) tracking these on our test-plan (m-r testing of builds to follow).
(In reply to Benoit Jacob [:bjacob] from comment #33)
> So this is the only area where I could be concerned about possible
> regressions: what actually happens now on a device that doesn't support
> OpenGL layers i.e. any device without OpenGL ES 2 support? See bug 778175
> which is specifically about these devices. An example is the HTC Wildfire /
> Buzz.

So on a HTC Wildfire we now crash a bit later it seems. UI shows up and crash is 4 or so seconds later.
Thanks for checking this. Kevin's result in comment 37 is probably enough in the way of testing devices not supporting OpenGL ES2, and Aaron's seems enough testing of supporting devices. I would be very interested in knowing what happens on chinese imapx200 devices (such as the one we just received in the Toronto office) as these sort of support ES2 but have bugs in practice so that we were never able to run on them; but I really wouldn't block on that.
(In reply to Benoit Jacob [:bjacob] from comment #28)
> That explains why we get so much more crashes with firefox 16. It doesn't
> seem to explain though why fennec versions >= 17 still have crashes.
The fix of bug 813818 which is a regression from bug 806369 is only in 20.0 and above.

(In reply to Roland Tanglao :rolandtanglao from comment #32)
> https://support.mozilla.org/kb/firefox-android-crashes-startup-how-fix
I have a few comments:
* The important notes should be a warning (pink instead of blue).
* The support of ARMv6 devices and the exception for Vivante GPUs in system requirements is missing and it's the same for https://support.mozilla.org/kb/how-do-i-install-firefox-android-device (see https://support.mozilla.org/kb/will-firefox-work-my-mobile-device). You should include a template for those three articles that use it.
(In reply to Roland Tanglao :rolandtanglao from comment #32)
> https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix
I have another comment:
* Not every startup crashes can be fixed by those steps. There are indeed *valid* startup crashes when Firefox is really not supported. So you should mention that it concerns only startup crashes that have appeared since February 4.
Crash Signature: libxul.so@0x1253dd5 | png_get_user_transform_ptr] [@ mozalloc_abort | __sread] → libxul.so@0x1253dd5 | png_get_user_transform_ptr] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5 | 0 (deleted)@0x11f911f] [@ mozalloc_abort | __swrite | libxul.so@0x1253dd5 | 0 (deleted)@0x11f611f] [@ mozalloc_abort | __sread] [@ mozalloc_abort | …
(In reply to Benoit Jacob [:bjacob] from comment #28)
> That explains why we get so much more crashes with firefox 16. It doesn't
> seem to explain though why fennec versions >= 17 still have crashes.

This may be explained by the fact that only FF16 users were crashing, and continued to crash after upgrading to FF18.0. If that's the case, your fix should resolve 100% of the cases on FF18.
Hi all:

I have updated the SUMO KB article and asked users to upgrade to 18.0.2:
https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix

Thanks to Scoobidiver, Alice and underpass and all who have given feedback on the KB article!

I will respond to the feedback on the article discussion forum tomorrow at:
https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix/discuss

Please post any additional feedback on the KB article at:
https://support.mozilla.org/en-US/kb/firefox-android-crashes-startup-how-fix/discuss
Read the SUMO page, +1 to Roland!

In other rather good news, the fix seems to be working: yesterday the crash rate was only half of what it was two days ago:

$ for p in `seq 1 7`; do echo "2013020$p : `zcat 2013020$p-pub-crashdata.csv.gz | grep 'OpenGL-accelerated layers are a hard requirement on this platform' | grep -v 'An error occurred earlier while querying gfx info' | wc -l`"; done
20130201 : 3
20130202 : 3
20130203 : 0
20130204 : 11022
20130205 : 107942
20130206 : 110940
20130207 : 58334
Oh and restricting to 18.0 gives this picture:

bjacob:~/crash-stats$ for p in `seq 1 7`; do echo "2013020$p : `zcat 2013020$p-pub-crashdata.csv.gz | grep 'OpenGL-accelerated layers are a hard requirement on this platform' | grep -v 'An error occurred earlier while querying gfx info' | grep 18\\.0 | wc -l`"; done
20130201 : 3
20130202 : 3
20130203 : 0
20130204 : 666
20130205 : 9862
20130206 : 12666
20130207 : 8604
Target Milestone: --- → Firefox 21
Even more, it looks a lot like we're not seeing this in 18.0.2, as expected. :)

Fewer crashes with the other versions could also just mean that those people abandon Firefox, after all.
Why is this bug still open?
Is there a plan in the future (with a better blocklist service) to revert the change of the forced layer pref? If yes, shouldn't it be in a new dependent bug?
Flags: needinfo?(bjacob)
I think I just put [leave open] as I wasn't sure then that it would fix it. We can close this now based on comment 45.

I'm not sure what to do about this in the longer term. force-enabling feels weird, but since this feature is necessary to start up on android, making it depend on blacklisting is creating artificial problems as we just got here.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(bjacob)
Resolution: --- → FIXED
Whiteboard: [native-crash][startupcrash][leave open][str in comment 28] → [native-crash][startupcrash][str in comment 28]
Status: RESOLVED → VERIFIED
(In reply to Benoit Jacob [:bjacob] from comment #47)
> force-enabling feels weird, but since this feature is necessary to start up on android
I think it makes Firefox for Android crash on desktop with emulators. See bp-9f331178-c8e0-4e11-b5f7-dae572130209.
Is ANDROID the platform flag or the Fennec flag?
(In reply to Scoobidiver from comment #48)
> I think it makes Firefox for Android crash on desktop with emulators. See
> bp-9f331178-c8e0-4e11-b5f7-dae572130209.

This is an interesting crash. It's an x86 emulator by the looks of it. The logcat from the crash has this:

I Gecko   : An error occurred earlier while querying gfx info: eglChooseConfig returned zero OpenGL ES2 configs. Maybe this device does not support OpenGL ES2?.  
I Gecko   : Logging GL tracing output to /data/data/org.mozilla.fennec/firefox.trace
I Gecko   : Attempting load of /data/local/egltrace.so
I Gecko   : Attempting load of libEGL.so 
E libagl  : eglChooseConfig()
E libagl  : eglChooseConfig() - numConfigs = 8 possibleMatch=FF
E libagl  : eglChooseConfig() - attr=12339 val=4
E libagl  : eglChooseConfig() - attr=12352 val=4
E libagl  : eglChooseConfig() - possibleMatch is now 0
E libagl  : eglChooseConfig() - and finally possibleMatch=0
E libagl  : eglChooseConfig() - num_config = 0
E libagl  : eglChooseConfig()
E libagl  : eglChooseConfig() - numConfigs = 8 possibleMatch=FF
E libagl  : eglChooseConfig() - attr=12339 val=4
E libagl  : eglChooseConfig() - attr=12352 val=4
E libagl  : eglChooseConfig() - possibleMatch is now 0
E libagl  : eglChooseConfig() - and finally possibleMatch=0
E libagl  : eglChooseConfig() - num_config = 0
I Gecko   : Failed to create EGL config! 
I Gecko   : ###!!! ABORT: We need a context on Android: file ../../../gfx/layers/opengl/LayerManagerOGL.cpp, line 498
E Gecko   : mozalloc_abort: ###!!! ABORT: We need a context on Android: file ../../../gfx/layers/opengl/LayerManagerOGL.cpp, line 498

> Is ANDROID the platform flag or the Fennec flag?

Which "ANDROID" are you referring to here? Is it a field in the crash report?
Last crash seems to be on the 2/7
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #49)
> This is an interesting crash. It's an x86 emulator by the looks of it.
Is it a consequence of this fix or not?

> Which "ANDROID" are you referring to here? Is it a field in the crash report?
The one in the patch:
#ifdef ANDROID
(In reply to Scoobidiver from comment #51)
> > This is an interesting crash. It's an x86 emulator by the looks of it.
> Is it a consequence of this fix or not?

I don't think so; it is probably unrelated.

> > Which "ANDROID" are you referring to here? Is it a field in the crash report?
> The one in the patch:
> #ifdef ANDROID

That flag is set on Fennec and B2G builds. It will be set regardless of whether Fennec is running on an emulator or on a real device.
tracking-fennec: ? → ---
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.