[meta] Firefox 44 on android crashing in [@ libGLESv2_adreno.so@ ...]

NEW
Unassigned

Status

()

Core
Graphics
P3
critical
3 years ago
9 months ago

People

(Reporter: alessandro, Unassigned, NeedInfo)

Tracking

(4 keywords)

44 Branch
ARM
Android
crash, crashreportid, top50, topcrash-android-armv7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44- wontfix, firefox45- wontfix, firefox46- wontfix, firefox50 affected, firefox51 affected, firefox52 wontfix, firefox53 affected, firefox54 affected)

Details

(Whiteboard: [gfx-noted], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Android 5.1.1; Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Build ID: 20151026030422

Steps to reproduce:

zooming any and out any web pages after two or three time makes nightly 44 on android either crashing or makes web pages all light gray.
it over a month it s happening PLEAE FIX IT

Comment 1

3 years ago
Same here. Build 44 Oa2

Comment 2

2 years ago
Needs a crash ID / stacktrace.
Flags: needinfo?(ale160382)

Comment 3

2 years ago
Hello. How can i upload the information you are requesting?
Flags: needinfo?(hdtrestini)

Comment 4

2 years ago
Created attachment 8715081 [details]
tmp_19664-Submitted Crash Reports-1316348657.pdf

List from about:crashes
[Tracking Requested - why for this release]: Regression

Some crashlog reports:
https://crash-stats.mozilla.com/report/index/3bea5d58-af8c-4bf3-a972-b7c2b2160203
https://crash-stats.mozilla.com/report/index/f0e92290-a1e9-49f2-8386-466ac2160102
https://crash-stats.mozilla.com/report/index/805b68b2-35c8-4237-ba7c-378bb2160102
https://crash-stats.mozilla.com/report/index/7dea52b9-f919-4a49-a2f7-19b5e2160101

Looks like it's top crash on Android.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ libGLESv2_adreno.so@0x13d76c ] [@ libGLESv2_adreno.so@0x13a91a ] [@ libGLESv2_adreno.so@0x13cb9c ] [@ libGLESv2_adreno.so@0x13d67e ] [@ libGLESv2_adreno.so@0x13c378 ]
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox47: --- → affected
tracking-firefox44: --- → ?
tracking-firefox45: --- → ?
tracking-firefox46: --- → ?
tracking-firefox47: --- → ?
Ever confirmed: true
Flags: needinfo?(ale160382)
Keywords: stackwanted → crashreportid, regression, regressionwindow-wanted, top50, topcrash, topcrash-android-armv7
OS: Unspecified → Android
Hardware: Unspecified → ARM
Summary: Firefox 44 on android crashing like crazy → Firefox 44 on android crashing in [@ libGLESv2_adreno.so@ ...]
Milan can someone look at this?
Flags: needinfo?(milan)
tracking-firefox45: ? → +
tracking-firefox46: ? → +
tracking-firefox47: ? → +
Assignee: nobody → jgilbert
Flags: needinfo?(milan) → needinfo?(jgilbert)
Looks like more OOMs.

Alessandro, is this actually any site, or just some (or even most) that you regularly browse?

Some urls would be helpful.
Flags: needinfo?(ale160382)
It looks like it's generally under glDrawArrays, however at least one report is not: (though it is crashing in libGLES2)
https://crash-stats.mozilla.com/report/index/f0e92290-a1e9-49f2-8386-466ac2160102

I echo that this may be OOMs, but in the driver. The driver may be lazily creating a non-trivial buffer.
Flags: needinfo?(jgilbert)
Whiteboard: [gfx-noted]

Comment 9

2 years ago
@Jamie: this happens with any site, especially if they contain a lot of graphics, embedded flash videos, etc.  Regards, Hector.

Comment 10

2 years ago
Here's another example.  This crash happened a few minutes ago, scrolling through a list of books founs athttp://hundredzeros.com/:

https://crash-stats.mozilla.com/report/index/e1657dea-f3dc-4b4e-920c-f9b982160210
Thanks very much for the url. The reason I'm trying to distinguish between what feels like any site and truly *any* site, is that while I'm sure they're equally frustrating for affected users, knowing specific sites massively helps us find and fix the problems.

On http://hundredzeros.com, I notice that sometimes each of the book "cards" gets its own layer. This seems occur if I scroll as the page is still loading. This causes us to allocate a huge number of textures, and crash. I'll do some sleuthing into why we're giving each card its own layer.
We layerize the cards because javascript is setting the "left" and "top" properties, and we therefore immediately decide the items are animated and give them their own layers. The page actually works fine with javascript disabled - it seems to only set these values once, and it sets them to the existing value anyway.

Here we have a wider problem - we cannot go about creating this many medium-sized layers and thinking we'll get away with it.

But also a more specific problem - should setting those properties once from javascript indicate the frame is animated?

Some of the public methods in ActiveLayerTracker increment the restyle counts by 1 at a time, and we only consider a frame animated at 2 or more. But NotifyInlineStyleRuleModified(), here called by nsDOMCSSAttributeDeclaration::SetPropertyValue(), immediately sets it to 0xFF. Should we reconsider this? Also, should we consider ignoring a property set when its value doesn't actually change?
Filed 1247336 for above issue.

More urls would help find more :)
See Also: → bug 1247336

Comment 15

2 years ago
None of those are sites I visited, so I can't give you details.  I will post some for your information soon, after I go through my browser history...
Given that this one does not have a fix yet, too late for Fx44.
status-firefox44: affected → wontfix
tracking-firefox44: ? → -

Comment 18

2 years ago
The following crash (https://crash-stats.mozilla.com/report/index/bp-cd2e35f4-2ff8-4789-a331-cce7e2160217) occurred happened after clicking on the Show Other Threads link and zomming in at the following sitehttps://crash-stats.mozilla.com/report/index/51247b54-496e-4c15-9a23-1d1c32160216.

Comment 19

2 years ago
(In reply to H. D. Trestini from comment #18)
> The following crash
> (https://crash-stats.mozilla.com/report/index/bp-cd2e35f4-2ff8-4789-a331-
> cce7e2160217) occurred happened after clicking on the Show Other Threads
> link and zomming in at the following
> sitehttps://crash-stats.mozilla.com/report/index/51247b54-496e-4c15-9a23-
> 1d1c32160216.

The message should have read:

The following crash (https://crash-stats.mozilla.com/report/index/bp-cd2e35f4-2ff8-4789-a331-cce7e2160217) occurred after clicking on the Show Other Threads link and zooming in on the page, at the following site: https://crash-stats.mozilla.com/report/index/51247b54-496e-4c15-9a23-1d1c32160216.
(In reply to H. D. Trestini from comment #19)
> ...
> https://crash-stats.mozilla.com/report/index/51247b54-496e-4c15-9a23-
> 1d1c32160216.

This last one has a few of these failures: https://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/TiledContentClient.cpp#775 (we fail to get the back buffer.)
Jeff, is this actionable on our side?
Flags: needinfo?(jgilbert)
(In reply to Milan Sreckovic [:milan] from comment #21)
> Jeff, is this actionable on our side?

I cannot reproduce it with my hardware. (2GB Adreno 320) I'll see if I have a lower-spec Adreno to test with.

I do not think this is easily actionable. I think we need to add heuristics to reduce/eliminate layerization when system memory is low.
Flags: needinfo?(jgilbert)
Jamie, is any of your layerization work going to help here?
Flags: needinfo?(jnicol)
Jamie is on PTO, but I think I can add a partial answer. The work in bug 1247554 does limit some of our layerization activity, but not all of it. We still need a more general solution that will allow us to put cap on the max number of layer pixels.
we're also uplifting bug 1247336 and bug 1250517 which should help on certain sites. the other layerization fixes I've managed this cycle are unfortunately only fixing regressions on nightly so won't help stable.

I'm going to look into what snorp mentioned in the above comment next. unfortunately it's hard to do accurately. we could also implement something like bug 1247437 as a safety net. hopefully we can get those done next cycle.
Flags: needinfo?(jnicol)
(In reply to Jamie Nicol [:jnicol] from comment #25)
> we're also uplifting bug 1247336 and bug 1250517 which should help on
> certain sites. the other layerization fixes I've managed this cycle are
> unfortunately only fixing regressions on nightly so won't help stable.
> 
> I'm going to look into what snorp mentioned in the above comment next.
> unfortunately it's hard to do accurately. we could also implement something
> like bug 1247437 as a safety net. hopefully we can get those done next cycle.

Alright, it sounds like we're investigating paths forward elsewhere. Unassigning myself now since investigation is more or less done.
Assignee: jgilbert → nobody
status-firefox45: affected → wontfix
Should we close this bug then? Nothing actionable, work continuing in other bugs?
Wontfix for 46, in the meantime.
status-firefox46: affected → wontfix
Flags: needinfo?(jgilbert)
Making this a meta bug
Flags: needinfo?(jgilbert)
Summary: Firefox 44 on android crashing in [@ libGLESv2_adreno.so@ ...] → [meta] Firefox 44 on android crashing in [@ libGLESv2_adreno.so@ ...]
Dropping the *wanted keywords and status flag since this is now a Meta bug. We can track those things in the dependencies.
status-firefox47: affected → ---
Keywords: regressionwindow-wanted
[Tracking Requested - why for this release]: Doesn't make sense to track a meta bug.
tracking-firefox45: + → ?
tracking-firefox46: + → ?
tracking-firefox47: + → ?
Keywords: regression

Updated

2 years ago
tracking-firefox45: ? → -
tracking-firefox46: ? → -
tracking-firefox47: ? → ---
Adding more signatures to this bug.
Crash Signature: [@ libGLESv2_adreno.so@0x13d76c ] [@ libGLESv2_adreno.so@0x13a91a ] [@ libGLESv2_adreno.so@0x13cb9c ] [@ libGLESv2_adreno.so@0x13d67e ] [@ libGLESv2_adreno.so@0x13c378 ] → [@ libGLESv2_adreno.so@0x13d76c ] [@ libGLESv2_adreno.so@0x13a91a ] [@ libGLESv2_adreno.so@0x13cb9c ] [@ libGLESv2_adreno.so@0x13d67e ] [@ libGLESv2_adreno.so@0x13c378 ] [@ libGLESv2_adreno.so@0x13c034 ] [@ libGLESv2_adreno.so@0x13923e ] [@ …
Keywords: topcrash
Crash Signature: [@ libGLESv2_adreno.so@0x13d76c ] [@ libGLESv2_adreno.so@0x13a91a ] [@ libGLESv2_adreno.so@0x13cb9c ] [@ libGLESv2_adreno.so@0x13d67e ] [@ libGLESv2_adreno.so@0x13c378 ] [@ libGLESv2_adreno.so@0x13c034 ] [@ libGLESv2_adreno.so@0x13923e ] [@ … → [@ libGLESv2_adreno.so@0x13d76c ] [@ libGLESv2_adreno.so@0x13a91a ] [@ libGLESv2_adreno.so@0x13cb9c ] [@ libGLESv2_adreno.so@0x13d67e ] [@ libGLESv2_adreno.so@0x13c378 ] [@ libGLESv2_adreno.so@0x13c034 ] [@ libGLESv2_adreno.so@0x13923e ] [@ …
We've seen a 4x dip in crashes starting on August 4, going from ~400/day to ~130/day placing this around #40 @ 0.71% in Fennec 48 at this point.
Crashes reported over the last week:
> 49.*:    88
> 50.*: 1,290
> 51.*:   108
> 52.*:     3
> 53.*:     1
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.