Closed Bug 1532456 Opened 6 years ago Closed 4 years ago

Crash in mozilla::layers::CompositorOGL::Initialize

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix

People

(Reporter: jgilbert, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [priority:low])

Crash Data

+++ This bug was initially created as a clone of Bug #1420745 +++

This bug was filed from the Socorro interface and is
report bp-252c8d15-38fc-4b9d-a25e-620fe0171124.

This is topcrash #3 in the android nightly 20171123100056.

Top 10 frames of crashing thread:

0 libxul.so mozilla::layers::CompositorOGL::Initialize gfx/layers/opengl/CompositorOGL.cpp:238
1 libxul.so mozilla::layers::CompositorBridgeParent::NewCompositor gfx/layers/ipc/CompositorBridgeParent.cpp:1481
2 libxul.so mozilla::layers::CompositorBridgeParent::InitializeLayerManager gfx/layers/ipc/CompositorBridgeParent.cpp:1412
3 libxul.so mozilla::layers::CompositorBridgeParent::AllocPLayerTransactionParent gfx/layers/ipc/CompositorBridgeParent.cpp:1523
4 libxul.so mozilla::layers::PCompositorBridgeParent::OnMessageReceived ipc/ipdl/PCompositorBridgeParent.cpp:840
5 libxul.so mozilla::ipc::MessageChannel::DispatchAsyncMessage ipc/glue/MessageChannel.cpp:2114
6 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2044
7 libxul.so mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1923
8 libxul.so MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:452
9 libxul.so MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:460

=============================================================

Priority: P1 → P3

99% of these Fennec 67 Nightly crashes are 32-bit ARM, even though about 70% of Fennec Nightly users are running ARM64 Fennec builds.

Hardware: Unspecified → ARM

Is this bug actionable, Jeff?

Flags: needinfo?(jgilbert)

Gonna be hard to, but some crashes seem like real users, at least:
https://crash-stats.mozilla.com/report/index/7c836415-50ab-4e97-858d-45b0f0190306

Flags: needinfo?(jgilbert)
Depends on: 1536033

Updating 68esr tracking flag since we are seeing regular crashes on Fennec nightly in this signature.

status-firefox-esr68: --- → affected

Although we are seeing regular crashes on nightly, 68 release so far only has 333 crashes. Let's see how the volume plays out in the next release. I don't think we need to change the priority on this one yet.

Also, the top crashing device appears to be an emulator - AOSP on ARM Emulator. The next top crashing device is ONEPLUS A6003. After that there are again several emulator crashes. So it looks like about 85 of the crashes in the last 7 days are coming from emulators.

This is the top crash currently on Fennec beta, but an emulator is at the top of the list. Currently on 68 release we have less than 60 crashes overall.

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #6)

This is the top crash currently on Fennec beta, but an emulator is at the top of the list. Currently on 68 release we have less than 60 crashes overall.

Actually, this is the top crash on Fennec nightly, not beta. Sorry for the confusion.

We still have a Fennec Nightly?

Yes, shipping off ESR68.

See Also: → 1628545

Looks like there is a recent spike in Fenix Nightly for this crash, can somebody look at it?

Priority: P3 → --

Jeff, could this be reprioritized? there seems to be a spike of this crash in Android Nightly: https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Alayers%3A%3ACompositorOGL%3A%3AInitialize

also the graph seems completely off, on crash stats I see 3500 crashes in the last week.

Flags: needinfo?(jmuizelaar)

Jeff, is there any reason this could have spiked recently?

Flags: needinfo?(jmuizelaar) → needinfo?(jgilbert)

Can we add some logging to the crash reports so that we better understand why it's failing?

Wasn't me!
:snorp?

Flags: needinfo?(jgilbert) → needinfo?(snorp)

All of the crash reports I've looked at seem to have some shader compilation issues. Maybe that's related?

https://crash-stats.mozilla.org/report/index/8b681391-b63f-43a9-bbb9-2096f0201223#tab-metadata

Flags: needinfo?(snorp)

One reason of crashes seems to related to Bug 1700848.

Depends on: 1700848
Blocks: gfx-triage

Various GPUs have Failed to create EGLSurface (t=203.701) |[1][GFX1-]: Fallback (SW-)WR to Basic in the graphics critical error

All of the Mesa Intel GPUs seem to have Failed to compile vertex shader: composite_TEXTURE_EXTERNAL 0:42(13): error: no matching function for call totextureSize(samplerExternalOES, int)';` This should be dealt with in a separate bug, but could mean that everyone on those GPUs is falling back (to layers or swgl depending on version) all of the time.

Also interesting that there are no reports from 92-beta. Maybe something was broken in the fallback code up until 91

No longer blocks: gfx-triage

There have now been (only 4) crashes in 92 https://crash-stats.mozilla.org/report/index/fd1e33d4-1c06-401d-a26f-dc9020210824, but the version number looks like it could be a non-standard build.

I wonder if this may have morphed in to bug 1726792 from 92 onwards. Seems to affect the same devices, and the fallback logic has changed so we now fall back to software webrender rather than layers.

In bug 1726792 Nical has confirmed that some STR that caused this crash signature on an older verion now cause bug 1726792's signature. So we expect this to fade away once 92 is released, but bug 1726792 to spike

See Also: → 1726792

This indeed morphed when switching from layers to swgl, and the swgl bug was fixed by 1747116

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