778175 - Startup crash on devices incompatible with OpenGL ES 2.0 (e.g. HTC Wildfire)

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Black Eco]

Attachment: alogcat.2012-07-27-18-10-27+0200.txt

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713224749

Steps to reproduce:

I launched the app for the first time


Actual results:

Crashed after few seconds.

Comment 1

[Black Eco]

Phone is actually a HTC Wildfire (codename Buzz) running CyanogenMod 7.2.

Comment 2

[Scoobidiver (away)]

> I/Gecko   ( 9712): An error occurred earlier while querying gfx info:
> eglChooseConfig returned zero configs. 
> I/Gecko   ( 9712): ###!!! ABORT: OpenGL-accelerated layers are a hard requirement
> on this platform. Cannot continue without support for them.: file /builds/slave
> /m-aurora-andrd-armv6-ntly/build/widget/xpwidgets/nsBaseWidget.cpp, line 851
A GPU supporting OpenGL ES 2.0 is required.

Comment 4

[Scoobidiver (away)]

Bug 771774 is specific to Vivante GPUs that are supposed to be compatible with OpenGL ES 2.0. I undupe it.

Benoit Jacob [:bjacob] wrote in bug 771774 comment 13:
> It's not surprising that ARMv6 phones would be overrepresented among phones
> not capable of OpenGL ES 2, although technically ARMv6 is orthogonal to
> OpenGL support. If we decide that that's an issue and assuming we keep
> confirming from the crash reports and googling that these phones don't have
> OpenGL ES 2 support, then the only thing we might conceivably do about this
> would be to add either OpenGL ES 1.x support or non-OpenGL support. OpenGL
> ES 1.x support would be expensive to code, test, and maintain, and might
> require OpenGL extensions that such devices wouldn't support (for example,
> if we need to convert between BGRA and RGBA, that's going to require
> fragment shaders or other extensions). Doing non-OpenGL support would be
> less expensive for us but would give poor performance, especially on
> underpowered ARMv6 phones.

Comment 5

[Chris Peterson [:cpeterson]]

Benoit, can you recommend someone to investigate this startup crash for devices without OpenGL ES 2.0?

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

What do you expect/hope to be done here?

Firefox/Android does not support at all running on devices without OpenGL ES 2 support. There is an explicit startup assertion about that. As I said in the comment that Scoobidiver pasted above (comment 4), supporting these devices would be a lot of work and the results and there is a risk that the only way would be pure software rendering (no OpenGL) in which case performance would be limited and battery usage would be high.

So the only thing that could conceivably happen here would be if we decided to go for this after all. Such an expensive and risky move would have to be backed by solid data. Do we know how many % of the market has non-GLES2-capable hardware?

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

CC'ing KaiRo:

We need a non-trivial query in the crash database to be performed:

please measure the percentage, among Firefox Android version 16+ (currently Aurora and Nightly) crash reports, how many % have AppNotes containing the following substring:

  OpenGL-accelerated layers are a hard requirement on this platform

I.e. this fatal assertion message:
https://bug766251.bugzilla.mozilla.org/attachment.cgi?id=636462

Thanks!

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

I would also like to know the values for ARMv7 and for ARMv6 devices, separately. And among the phones that have this crash, I would like to know what devices they are: this is written at the end of the AppNotes, e.g.

Model: AN10G2, Product: rk29sdk, Manufacturer: unknown, Hardware: rk29board

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

Oh wait --- I forgot, but the AppNotes are entirely stored in public crash-stats archives, so anyone can mine that information. Sorry KaiRo for the disturbance.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

So here's the Bash command I ran:

$ for x in `echo 0726 0727 0728 0729 0730 0731 0801 0802 0803 0804 0805 0806 | xargs echo`; do echo "$x `zcat 2012$x-pub-crashdata.csv.gz | grep FennecAndroid.1[67].0a[12] | grep -v armv6 | wc -l` `zcat 2012$x-pub-crashdata.csv.gz | grep FennecAndroid.1[67].0a[12] | grep 'OpenGL-accelerated layers are a hard requirement on this platform'| grep -v armv6 | wc -l` `zcat 2012$x-pub-crashdata.csv.gz | grep FennecAndroid.1[67].0a[12] | grep armv6 | wc -l` `zcat 2012$x-pub-crashdata.csv.gz | grep FennecAndroid.1[67].0a[12] | grep 'OpenGL-accelerated layers are a hard requirement on this platform'| grep armv6 | wc -l`"; done

and here's, after some formatting, what it tells us. Note that this is only among Android Firefox 16.0 and 17.0 crashes, whence the small numbers. By "no-GLES2 crash" I mean the crash being discussed here.


Date|ARMv7 crashes|ARMv7 no-GLES2 crashes|ARMv6 crashes|ARMv6 no-GLES2 crashes
----+-------------+----------------------+-------------+----------------------
0726|          714|                    10|           19|                    18
0727|          577|                     8|           35|                    29
0728|          561|                     2|           18|                    15
0729|          498|                     0|           13|                    10
0730|          416|                     4|           16|                    11
0731|          418|                     1|           12|                    11
0801|          453|                     5|           20|                    15
0802|          438|                     8|           12|                    10
0803|          416|                     0|            8|                     0
0804|          453|                    12|            4|                     0
0805|          406|                     0|            9|                     0
0806|          373|                     0|            6|                     0


So, what do we see here?

On ARMv7, crash levels are relatively stable, and the present crasher is rather minor: it accounts for between 0 and 2% of total crashes. Probably not worth extra work for us.

On ARMv6 the story is different and harder to interprete due to what could be noise: numbers are very low as only a small minority of our Aurora/Nightly testers are on ARMv6. We see that until August 2nd (0802), the present crash accounted for the *majority* of crashes... but suddenly, on August 3rd (0803), it was gone (see the 0's in the right column)! And crash levels went down accordingly.

Could anything explain that sudden disparition of this crasher on ARMv6 on August 3rd? Or is this just noise? The sample set is small enough for it to be noise.

Comment 11

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

The other option is to replace the crash with a more user-friendly error message.

Comment 13

[Scoobidiver (away)]

According to Google, 90.7% of Android devices support OpenGL ES 2.0: http://developer.android.com/about/dashboards/index.html#OpenGL

I agree with comment 11 to display an error message on startup instead of crashing.

Comment 14

[Robert Kaiser]

(In reply to Benoit Jacob [:bjacob] (on vacation this Wed. August 8th) from comment #7)
> CC'ing KaiRo:

Looks like you found it yourself. If you want to dig into data not exposed in the CSV but present in the raw JSON, you can file a bug against the Data Request component of Socorro.

Comment 15

[Chris Peterson [:cpeterson]]

Can we block no-GLES2 devices in the Play Store or during .apk installation?

Comment 16

[Merike Sell (:merike)]

(In reply to Benoit Jacob [:bjacob] from comment #10)
> So here's the Bash command I ran:
> 
> $ for x in `echo 0726 0727 0728 0729 0730 0731 0801 0802 0803 0804 0805 0806
> | xargs echo`; do echo "$x `zcat 2012$x-pub-crashdata.csv.gz | grep
> FennecAndroid.1[67].0a[12] | grep -v armv6 | wc -l` `zcat
> 2012$x-pub-crashdata.csv.gz | grep FennecAndroid.1[67].0a[12] | grep
> 'OpenGL-accelerated layers are a hard requirement on this platform'| grep -v
> armv6 | wc -l` `zcat 2012$x-pub-crashdata.csv.gz | grep
> FennecAndroid.1[67].0a[12] | grep armv6 | wc -l` `zcat
> 2012$x-pub-crashdata.csv.gz | grep FennecAndroid.1[67].0a[12] | grep
> 'OpenGL-accelerated layers are a hard requirement on this platform'| grep
> armv6 | wc -l`"; done

Could you maybe re-run these stats at some point to see if bug 732629 fixed made any difference? This prevented at least some Wildfire/Buzz phones with 2.2 submitting reports.

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

Updated table:

Date|ARMv7 crashes|ARMv7 no-GLES2 crashes|ARMv6 crashes|ARMv6 no-GLES2 crashes
----+-------------+----------------------+-------------+----------------------
0726|          714|                    10|           19|                    18
0727|          577|                     8|           35|                    29
0728|          561|                     2|           18|                    15
0729|          498|                     0|           13|                    10
0730|          416|                     4|           16|                    11
0731|          418|                     1|           12|                    11
0801|          453|                     5|           20|                    15
0802|          438|                     8|           12|                    10
0803|          416|                     0|            8|                     0
0804|          453|                    12|            4|                     0
0805|          406|                     0|            9|                     0
0806|          373|                     0|            6|                     0
0807|          364|                     1|           24|                    16
0808|          421|                     5|           27|                    19
0809|          464|                     0|           17|                     6
0810|          430|                     6|           20|                     8
0811|          445|                    13|           27|                    14
0812|          434|                    12|           20|                    14
0813|          354|                     2|           36|                    22
0814|          450|                    31|           19|                    15

(In reply to Merike (:merike) from comment #16)
> Could you maybe re-run these stats at some point to see if bug 732629 fixed
> made any difference? This prevented at least some Wildfire/Buzz phones with
> 2.2 submitting reports.

Yep, this seems to be it. ARMv6 crash reports have resumed on Aug. 7.

(In reply to Kartikaya Gupta (:kats) from comment #11)
> The other option is to replace the crash with a more user-friendly error
> message.

Let's do that. But I'm no front-end developer. If I may make a suggestion: the java code in GfxInfoThread.java might be a good place to show this message, since it's java code and it's where we first find out that we're going to abort.

Comment 18

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

Adding uiwanted keyword to see if we can get a mockup of what such an error screen should look like. The screen should basically inform the user that their device doesn't support Firefox, even though they've managed to install it and run it.

Comment 19

[Scoobidiver (away)]

I added crash signatures in 15.0 matching aborts with abort message: "We need a context on Android: file /builds/slave/rel-m-rel-andrd-bld/build/gfx/layers/opengl/LayerManagerOGL.cpp, line 175" that was removed in 16.0 with bug 766251.

Comment 20

[Benoit Jacob [:bjacob] (mostly away)]

Instead of a UI, Scoobidiver and JP have argued, and I agree, that we should simply block these devices in the Google Play store. The bug for that seems to be 775237.

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

Marking this for tracking for now, when we deal with bug 775237 we can update accordingly.

Comment 22

[Alex Keybl [:akeybl]]

Let's let bug 775237 track the blocking, which is the most we can do for FF16 at this point.

Comment 23

[Scoobidiver (away)]

There's an exploitable stack trace: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak_P+|+nsBaseWidget%3A%3AComputeShouldAccelerate%28bool%29

Comment 24

[Robert Kaiser]

"mozalloc_abort | CrashReporter::AppendAppNotesToCrashReport(nsACString_internal const&)" continues to be a topcrash for ARMv6, BTW - it's always under the top 3 for any ARMv6 topcrash list I look at for Beta 19.

Comment 25

[Benoit Jacob [:bjacob] (mostly away)]

@ comment 24, that's a surprising/interesting signature. can you paste a crash link that has it?

Comment 26

[Robert Kaiser]

FWIW, I saw it in the list at https://crash-analysis.mozilla.com/rkaiser/2013-01-29/2013-01-29.fennecandroid.19.0b3.armv6.topcrash.html (and others from other days), the link to the list of those crashes is https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%20%7C%20CrashReporter%3A%3AAppendAppNotesToCrashReport%28nsACString_internal%20const%26%29 - as with most abort crashes, I guess there might be abort messages in the data that are way more useful than the signature.

Comment 27

[Scoobidiver (away)]

The new crash signature since 20.0 contains nsBaseWidget::ComputeShouldAccelerate but is also for several abort messages.
The abort message for this bug says that OpenGL ES 2.0 is required.

A solution to prevent a startup crash has been proposed in comment 18.

Comment 28

[Benoit Jacob [:bjacob] (mostly away)]

Ok, I get it now --- sorry. I was confused by "mozalloc_abort": for a moment, I thought it meant an allocation failure, which shouldn't happen there. Now I remember that mozalloc_abort really just means abort.

Comment 29

[Scoobidiver (away)]

Kevin, what is the new crash ID for a startup crash on HTC Wildfire?

Comment 30

[Kevin Brosnan [Ex-Mozilla]]

No crash reporter appears.

Comment 31

[Scoobidiver (away)]

Removing the topcrash keyword as we are now completely blind in crash stats.

Comment 32

[robin]

Hi, there are numerous people using Replicant [1] who are severely disadvantaged by mobile Firefox's reliance on OpenGL ES. Replicant is a free/libre mobile OS, based upon Android. Replicant strips out all the Google applications and proprietary code, including binary-only drivers such as the hardware graphics acceleration. Combined with Chromium also having OpenGL dependencies, this results in only the unmaintained Webview/Android browser being available to Replicant and other free mobile systems. At the time of writing, Webview has serious security flaws which Google are not going to fix. Given ongoing mistrust of Google and their policies, the number escaping Android for a fully free OS will only increase, hence the support from the Free Software Foundation [2]

According to the posts above, this bug only affects "a small share of the market". Firstly, I would disagree with the word market as Mozilla does not sell its software, but gives it away. Secondly, given that this share represents one of the best attempts at a free mobile OS, I would think it essential for Mozilla to provide support and usefully fix the bug, given its philosophical and ethical commitment to free software and an "open web". Demanding accelerated graphics which almost always rely on proprietary drivers sounds not at all open.

Quoting from Mozilla:
"The Internet is a global public resource that must remain open and accessible."
"You don’t have to make a case for open. You have to make a case for not open."
"Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional." [2]. And so on.

[1] http://replicant.us/
[2] http://www.fsf.org/news/fsf-launches-fundraising-program-for-replicant-the-fully-free-android-based-mobile-os
[3] https://www.mozilla.org/en-US/about/manifesto/


Regards,

Robin

Comment 33

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

(In reply to robin from comment #32)
> According to the posts above, this bug only affects "a small share of the
> market". Firstly, I would disagree with the word market as Mozilla does not
> sell its software, but gives it away.

Mozilla doesn't sell its software, but it's not free to make, either. The corporation half of Mozilla has to sustain itself in order to fund the development of the software, and in order to do that we have to think in terms of things like marketshare and number of users and growth. And along with that we have to think about prioritization and what gives the "biggest bang of the buck".

That being said, Mozilla's software *is* entirely open source, so you are free to contribute to it things that you wish to see, such as a non-GLES version of Fennec. If you are not able to personally contribute code, you can find people who will are willing to do so (if not for ideals, then at least for money). And if the code changes being requested are incompatible with the direction in which we are taking Firefox then you are of course also free to fork the code, as many have done in the past.

> Secondly, given that this share
> represents one of the best attempts at a free mobile OS, I would think it
> essential for Mozilla to provide support and usefully fix the bug, given its
> philosophical and ethical commitment to free software and an "open web".
> Demanding accelerated graphics which almost always rely on proprietary
> drivers sounds not at all open.
> 
> Quoting from Mozilla:
> "The Internet is a global public resource that must remain open and
> accessible."
> "You don’t have to make a case for open. You have to make a case for not
> open."
> "Individuals’ security and privacy on the Internet are fundamental and must
> not be treated as optional." [2]. And so on.

These are good points, but Mozilla has chosen a different direction in which to address the issue of there not being a free mobile OS. Specifically, we are investing immense amounts of time and effort into Firefox OS for exactly this reason - we want the mobile OS ecosystem to have viable open alternatives.

Comment 34

[Botond Ballo [:botond]]

Is anyone working on an open-source OpenGL ES driver, that Replicant could ship while still remaining fully open-source (and then use Firefox for Android as-is)?

Comment 35

[Warm Morning]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #33)
> (In reply to robin from comment #32)
> > According to the posts above, this bug only affects "a small share of the
> > market". Firstly, I would disagree with the word market as Mozilla does not
> > sell its software, but gives it away.
> 
> Mozilla doesn't sell its software, but it's not free to make, either. The
> corporation half of Mozilla has to sustain itself in order to fund the
> development of the software, and in order to do that we have to think in
> terms of things like marketshare and number of users and growth. And along
> with that we have to think about prioritization and what gives the "biggest
> bang of the buck".
> 
> That being said, Mozilla's software *is* entirely open source, so you are
> free to contribute to it things that you wish to see, such as a non-GLES
> version of Fennec. If you are not able to personally contribute code, you
> can find people who will are willing to do so (if not for ideals, then at
> least for money). And if the code changes being requested are incompatible
> with the direction in which we are taking Firefox then you are of course
> also free to fork the code, as many have done in the past.
> 
> > Secondly, given that this share
> > represents one of the best attempts at a free mobile OS, I would think it
> > essential for Mozilla to provide support and usefully fix the bug, given its
> > philosophical and ethical commitment to free software and an "open web".
> > Demanding accelerated graphics which almost always rely on proprietary
> > drivers sounds not at all open.
> > 
> > Quoting from Mozilla:
> > "The Internet is a global public resource that must remain open and
> > accessible."
> > "You don’t have to make a case for open. You have to make a case for not
> > open."
> > "Individuals’ security and privacy on the Internet are fundamental and must
> > not be treated as optional." [2]. And so on.
> 
> These are good points, but Mozilla has chosen a different direction in which
> to address the issue of there not being a free mobile OS. Specifically, we
> are investing immense amounts of time and effort into Firefox OS for exactly
> this reason - we want the mobile OS ecosystem to have viable open
> alternatives.

Yeah but will Firefox OS require proprietary video blobs? If it will, then this entire conversation is irrelevant to the larger issue: which is getting a modern browser onto a free and open source (mobile) distribution which you claim to support. Everything else is just marketing.

Comment 36

[Kevin Brosnan [Ex-Mozilla]]

This product is not supported.

Comment 37

[revuwa]

Really hope, I don't bother...

I come from a time travel to older Firefox (for Android) releases. 
I'm one of those crazy enthusiasts using Replicant but still want to use the internet without being incredible vulnerable, like this overview shows: 
http://redmine.replicant.us/boards/39/topics/8007?r=9081#message-9081

In this context, I've realized that I'm able to use Firefox 13.0 Beta 1:
https://ftp.mozilla.org/pub/mozilla.org/mobile/releases/13.0b1/android-xul/en-US/fennec-13.0b1.en-US.android-arm.apk
without any problems on Replicant, (and so without the OpenGL ES 2.0 BLOBs) and furthermore with amazingly speed(!)

This seems to be the last version, which works without that proprietary prerequisite because the next follow-up version, Firefox 14.0 Beta 1:
https://ftp.mozilla.org/pub/mozilla.org/mobile/releases/14.0b1/android/en-US/fennec-14.0b1.en-US.android-arm.apk
doesn't work without that BLOBs anymore.

What I try to say is: it was possible (and it was the Gecko engine)!

Sadly, I'm not a developer - otherwise I would make this to my job.
So I kindly wanted to ask, is there really no way to bring this possibility of a working Firefox back, for example as a (supported or unsupported) fallback on systems like Replicant, instead of simply force close the browser after the prerequisite-check?

How could I support in this case - even if I can't code?
Is there a need of a fundraising for that implementation, for example?

Thanks in advance for any help, support or reaction.