Closed Bug 778175 Opened 7 years ago Closed 5 years ago

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

Categories

(Firefox for Android :: Toolbar, defect, critical)

ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED INVALID
Tracking Status
firefox16 - ---

People

(Reporter: blackeco, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: crash, uiwanted, Whiteboard: [native-crash][startupcrash][armv6])

Attachments

(1 file)

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.
OS: Linux → Android
Hardware: x86_64 → ARM
Phone is actually a HTC Wildfire (codename Buzz) running CyanogenMod 7.2.
> 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.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Product: Fennec → Firefox for Android
Resolution: --- → DUPLICATE
Duplicate of bug: 771774
Duplicate of this bug: 778910
Whiteboard: [ARMv6]
Summary: Nightly crashes at start (HTC Buzz Wildifre CM7.2) → [ARMv6] Nightly crashes at start (HTC Buzz Wildifre CM7.2)
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.
Severity: normal → critical
Status: RESOLVED → REOPENED
Crash Signature: [@ mozalloc_abort ] [@ libmozalloc.so@0x1704 ]
Component: General → Graphics, Panning and Zooming
Ever confirmed: true
Keywords: crash
Resolution: DUPLICATE → ---
Summary: [ARMv6] Nightly crashes at start (HTC Buzz Wildifre CM7.2) → Startup crash on devices incompatible with OpenGL ES 2.0 (e.g. HTC Wildfire)
Whiteboard: [ARMv6]
Version: Firefox 16 → Trunk
Whiteboard: [native-crash][startupcrash]
Benoit, can you recommend someone to investigate this startup crash for devices without OpenGL ES 2.0?
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?
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!
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
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.
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.
The other option is to replace the crash with a more user-friendly error message.
Duplicate of this bug: 610401
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.
(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.
Can we block no-GLES2 devices in the Play Store or during .apk installation?
(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.
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.
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.
Keywords: uiwanted
Crash Signature: [@ mozalloc_abort ] [@ libmozalloc.so@0x1704 ] → [@ mozalloc_abort ] [@ libmozalloc.so@0x1704 ] [@ TouchBadMemory | mozalloc_abort | libms3c_yamaha.so@0x211f]
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.
Crash Signature: [@ mozalloc_abort ] [@ libmozalloc.so@0x1704 ] [@ TouchBadMemory | mozalloc_abort | libms3c_yamaha.so@0x211f] → [@ mozalloc_abort] [@ libmozalloc.so@0x1704] [@ TouchBadMemory | mozalloc_abort] [@ TouchBadMemory | mozalloc_abort | libms3c_yamaha.so@0x211f] [@ TouchBadMemory | mozalloc_abort | libsafetybox.so@0x211f] [@ TouchBadMemory | mozalloc_abort | libanima…
Keywords: topcrash
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.
Depends on: 775237
Marking this for tracking for now, when we deal with bug 775237 we can update accordingly.
Whiteboard: [native-crash][startupcrash] → [native-crash][startupcrash][armv6]
Depends on: 778404
Let's let bug 775237 track the blocking, which is the most we can do for FF16 at this point.
Depends on: 803796
Crash Signature: | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] → | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release()]
Crash Signature: | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release()] → | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()]
Crash Signature: | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()] → | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()] [@ mozalloc_abort(char const*)]
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
Crash Signature: | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()] [@ mozalloc_abort(char const*)] → | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()] [@ mozalloc_abort(char const*)] [@ mozalloc_abort(…
Crash Signature: | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()] [@ mozalloc_abort(char const*)] [@ mozalloc_abort(… → | system@framework@services.jar@classes.dex@0x18a263] [@ TouchBadMemory | mozalloc_abort | log_update_mask] [@ mozalloc_abort | nsStringBuffer::Release] [@ mozalloc_abort | nsStringBuffer::Release()] [@ mozalloc_abort | CrashReporter::AppendAppNotesTo…
"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 24, that's a surprising/interesting signature. can you paste a crash link that has it?
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.
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.
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.
Crash Signature: CrashReporter::AppendAppNotesToCrashReport(nsACString_internal const&)] [@ mozalloc_abort(char const*)] [@ mozalloc_abort(char const*) | NS_DebugBreak_P | nsBaseWidget::ComputeShouldAccelerate(bool)] → CrashReporter::AppendAppNotesToCrashReport(nsACString_internal const&)] [@ mozalloc_abort | arena_dalloc] [@ mozalloc_abort(char const*)] [@ mozalloc_abort(char const*) | NS_DebugBreak_P | nsBaseWidget::ComputeShouldAccelerate(bool)]
Kevin, what is the new crash ID for a startup crash on HTC Wildfire?
Flags: needinfo?(kbrosnan)
No crash reporter appears.
Flags: needinfo?(kbrosnan)
Removing the topcrash keyword as we are now completely blind in crash stats.
Keywords: topcrash
Crash Signature: [@ mozalloc_abort] [@ libmozalloc.so@0x1704] [@ TouchBadMemory | mozalloc_abort] [@ TouchBadMemory | mozalloc_abort | libms3c_yamaha.so@0x211f] [@ TouchBadMemory | mozalloc_abort | libsafetybox.so@0x211f] [@ TouchBadMemory | mozalloc_abort | libanima…
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
(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.
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)?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
This product is not supported.
Status: REOPENED → RESOLVED
Closed: 7 years ago5 years ago
Resolution: --- → INVALID
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.
You need to log in before you can comment on or make changes to this bug.