Crash in mozilla::gl::CreateSurfaceFromNativeWindow
Categories
(Firefox for Android Graveyard :: Toolbar, defect, P5)
Tracking
(firefox-esr68 unaffected, firefox-esr78 unaffected, firefox54 wontfix, firefox55 wontfix, firefox56 wontfix, firefox77 wontfix, firefox78 wontfix, firefox79 fixed, firefox80 fixed)
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox54 | --- | wontfix |
firefox55 | --- | wontfix |
firefox56 | --- | wontfix |
firefox77 | --- | wontfix |
firefox78 | --- | wontfix |
firefox79 | --- | fixed |
firefox80 | --- | fixed |
People
(Reporter: gchang, Assigned: mortimergoro)
Details
(Keywords: crash, Whiteboard: [fxr:p1])
Crash Data
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
This bug was filed from the Socorro interface and is report bp-f7ce1e30-b3cc-43a2-9e19-5692a0170619. ============================================================= Frame Module Signature Source Ø 0 libEGL.so libEGL.so@0xb77e Ø 1 libEGL.so libEGL.so@0x22106 Ø 2 libEGL.so libEGL.so@0x22106 Ø 3 libEGL.so libEGL.so@0xa47d Ø 4 libEGL.so libEGL.so@0xb757 5 libxul.so mozilla::gl::CreateSurfaceFromNativeWindow gfx/gl/GLLibraryEGL.h:281 6 libxul.so mozilla::gl::GLContextEGL::RenewSurface gfx/gl/GLContextProviderEGL.cpp:404 7 libxul.so mozilla::layers::CompositorBridgeParent::ResumeComposition gfx/layers/ipc/CompositorBridgeParent.cpp:705 8 libxul.so mozilla::layers::UiCompositorControllerParent::RecvResumeAndResize gfx/layers/ipc/UiCompositorControllerParent.cpp:72 9 libxul.so mozilla::layers::PUiCompositorControllerParent::OnMessageReceived obj-firefox/ipc/ipdl/PUiCompositorControllerParent.cpp:251 10 libxul.so mozilla::ipc::MessageChannel::DispatchSyncMessage ipc/glue/MessageChannel.cpp:1783 11 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:1743 12 libxul.so mozilla::ipc::MessageChannel::RunMessage ipc/glue/MessageChannel.cpp:1620 13 libxul.so mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1653 14 libxul.so MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:358 15 libxul.so MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:366 16 libxul.so MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:441 17 libxul.so base::MessagePumpDefault::Run ipc/chromium/src/base/message_pump_default.cc:36 18 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:231 19 libxul.so base::Thread::ThreadMain ipc/chromium/src/base/thread.cc:179 20 libxul.so ThreadFunc ipc/chromium/src/base/platform_thread_posix.cc:38 Ø 21 libc.so libc.so@0x12bb2 Ø 22 libc.so libc.so@0x1230a This is #22 topcrash for Firefox for android and there is a spike in the last 3 days.
Reporter | ||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 1•7 years ago
|
||
(In reply to Gerry Chang [:gchang] from comment #0) > This is #22 topcrash for Firefox for android and there is a spike in the > last 3 days. It looks like you were looking at the release channel data, it is #22 there. On 55 it is #43 and it doesn't appear on the topcrash list for 56 at all. Here is the graph showing the spike: https://crash-stats.mozilla.com/signature/?product=FennecAndroid&version=54.0&signature=mozilla%3A%3Agl%3A%3ACreateSurfaceFromNativeWindow&date=%3E%3D2017-05-27T15%3A19%3A43.000Z&date=%3C2017-06-27T15%3A19%3A43.000Z#graphs June 17 is where it really started picking up. Note that this all on the same buildid so it can't be used to get a regression range, but perhaps that's around when people started updating to 54 release? Or it might be some external factor. Not really sure. Either way, I doubt this is going to be worth a dot release to 54 and seeing as the crash volume is lower in 55+ I'm going to mark it as a P3 for now.
Comment 2•6 years ago
|
||
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Assignee | ||
Comment 3•4 years ago
|
||
There are some code paths where CreateSurfaceFromNativeWindow can be called without the GLLibraryEGL::EnsureInitialized check
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
•
|
||
This is one of our top crashers in FxR on Oculus Go: https://crash-stats.mozilla.org/report/index/d8751ecf-9bb5-4b77-ad90-6ce100200630
We haven't found a way to reproduce it, but checking the code I see that CreateSurfaceFromNativeWindow
doesn't perform the GLLibraryEGL::EnsureInitialized
check that others CreateXXX functions do. I think that not doing that check can be related to the crash.
Pushed by igorostizaga@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/885d2ba42467 Ensure EGL Library is initialized when calling CreateSurfaceFromNativeWindow. r=jgilbert
Comment 6•4 years ago
|
||
bugherder |
Assignee | ||
Comment 7•4 years ago
|
||
The speculative fix didn't work, we can still reproduce it in FxR.
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
ANativeWindow_fromSurface can return null. This leads to a crash in the eglCreateWindowSurface call.
Pushed by igorostizaga@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/53be083ebe2e Ensure ANativeWindow is not null before calling eglCreateWindowSurface r=jgilbert
Comment 10•4 years ago
|
||
bugherder |
Comment 11•4 years ago
|
||
Once the fix is verified, we will need to uplift to v79 beta.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Comment on attachment 9160898 [details]
Bug 1374571 - Ensure EGL Library is initialized when calling CreateSurfaceFromNativeWindow.
Beta/Release Uplift Approval Request
- User impact if declined: This fixes Firefox Reality's top crashing bug.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The patch does two things, it ensures the EGL library was initialized and then ensures the returned surface is not null.
- String changes made/needed: none
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Comment on attachment 9160898 [details]
Bug 1374571 - Ensure EGL Library is initialized when calling CreateSurfaceFromNativeWindow.
Approved for 79.0b6.
Updated•4 years ago
|
Comment 14•4 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Description
•