Closed Bug 1218607 Opened 9 years ago Closed 2 months ago

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

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Version:
44 Branch
Platform:
ARM
Android
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox44 - wontfix
firefox45 - wontfix
firefox46 - wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr60 --- wontfix
firefox53 --- wontfix
firefox-esr102 --- wontfix
firefox54 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- affected
firefox66 --- affected
firefox114 --- affected
firefox115 --- affected
firefox116 --- affected

People

(Reporter: ale160382, Unassigned)

References

Details

(5 keywords, Whiteboard: [gfx-noted])

Crash Data

Attachments

(1 file)

tmp_19664-Submitted Crash Reports-1316348657.pdf
23.76 KB, application/pdf
Details
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
Same here. Build 44 Oa2
Needs a crash ID / stacktrace.
Flags: needinfo?(ale160382)
Hello. How can i upload the information you are requesting?
Flags: needinfo?(hdtrestini)
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)
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]
@Jamie: this happens with any site, especially if they contain a lot of graphics, embedded flash videos, etc. Regards, Hector.
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: → 1247336
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: ? → -
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.
(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
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
Depends on: 1247336, 1247554, 1247437, 1250517
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
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 ] [@ libGLES…
Keywords: topcrash
Crash Signature: libGLESv2_adreno.so@0x1bdbc0 ] [@ libGLESv2_adreno.so@0x1c95ae ] [@ libGLESv2_adreno.so@0x1c5650 ] [@ libGLESv2_adreno.so@0x13c0c6 ] → libGLESv2_adreno.so@0x1bdbc0 ] [@ libGLESv2_adreno.so@0x1c95ae ] [@ libGLESv2_adreno.so@0x1c5650 ] [@ libGLESv2_adreno.so@0x13c0c6 ] [@ libGLESv2_adreno.so@0x122007 ]
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
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
Summary: [meta] Firefox 44 on android crashing in [@ libGLESv2_adreno.so@ ...] → [meta] Firefox on android crashing in [@ libGLESv2_adreno.so@ ...]
Depends on: 1507463

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ale160382) → needinfo?(bhood)
Severity: critical → S3
Flags: needinfo?(bhood)
Duplicate of this bug: 1705611
Duplicate of this bug: 1708393
Duplicate of this bug: 1649496
Duplicate of this bug: 1721834
Duplicate of this bug: 1509128
Duplicate of this bug: 1516324
Duplicate of this bug: 1721742
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 ] [@ libGLES… → [@ libc.so@0x28d68 | libc.so@0xf2cb | libGLESv2_adreno.so@0x81b1d] [@ libc.so@0x28fa8 | libc.so@0xf2bb | libGLESv2_adreno.so@0x81b3d] [@ libGLESv2_adreno.so@0x11dc50] [@ libGLESv2_adreno.so@0x122007] [@ libGLESv2_adreno.so@0x126748] [@ libGLESv2_adre…
status-firefox114: --- → affected
status-firefox115: --- → affected
status-firefox116: --- → affected
status-firefox-esr102: --- → wontfix

Copying crash signatures from duplicate bugs.

Crash Signature: libGLESv2_adreno.so@0xecb94] → libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32]

Copying crash signatures from duplicate bugs.

Crash Signature: libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32] → libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32] [@ libGLESv2_adreno.so@0x1b3cdc]

Copying crash signatures from duplicate bugs.

Crash Signature: libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32] [@ libGLESv2_adreno.so@0x1b3cdc] → libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32] [@ libGLESv2_adreno.so@0x1b3cdc] [@ libGLESv2_adreno.so@0x32fe72] [@ libGLESv2_adreno.so@0x3415ca]
See Also: → 1871069

Will, can we adjust the signature generation so that we don't include the address for libGLESv2_adreno.so like we do dlls with no symbols on Windows? I remember us making this change on Windows but don't remember the details of how we did that.

Crash Signature: libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32] [@ libGLESv2_adreno.so@0x1b3cdc] [@ libGLESv2_adreno.so@0x32fe72] [@ libGLESv2_adreno.so@0x3415ca] → libGLESv2_adreno.so@0xecb94] [@ libc.so@0x1a41a | libhwui.so@0x2fe32] [@ libGLESv2_adreno.so@0x1b3cdc] [@ libGLESv2_adreno.so@0x32fe72] [@ libGLESv2_adreno.so@0x3415ca]
Flags: needinfo?(willkg)

Jeff: Can you write up a bug for that? I don't remember offhand what we do for DLLs with no symbols. We can probably get someone to look at it in the next week.

Flags: needinfo?(willkg)
Depends on: 1895527
See Also: → 1897805

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: