Closed Bug 1562679 Opened 4 months ago Closed 4 months ago

Crash in [@ mozilla::gfx::OpenVRSession::SetupContollerActions]

Categories

(Core :: WebVR, defect, critical)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: marcia, Assigned: daoshengmu)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-e64c4758-7a08-454c-a9e7-182e20190701.

Seen while looking at nightly crash data: https://bit.ly/2KNZrJH. 21 crashes/5 installs on 69 nightly. No URLS for the nightly crashes. There are also a few single install crashes that happened in 66 and 67.

Top 10 frames of crashing thread:

0 xul.dll bool mozilla::gfx::OpenVRSession::SetupContollerActions gfx/vr/service/OpenVRSession.cpp:820
1 xul.dll bool mozilla::gfx::OpenVRSession::Initialize gfx/vr/service/OpenVRSession.cpp:311
2 xul.dll void mozilla::gfx::VRService::ServiceInitialize gfx/vr/service/VRService.cpp:260
3 xul.dll nsresult mozilla::detail::RunnableMethodImpl< xpcom/threads/nsThreadUtils.h:1176
4 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:523
5 xul.dll base::MessagePumpDefault::Run ipc/chromium/src/base/message_pump_default.cc:35
6 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
7 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
8 xul.dll base::Thread::ThreadMain ipc/chromium/src/base/thread.cc:192
9 xul.dll `anonymous namespace'::ThreadFunc ipc/chromium/src/base/platform_thread_win.cc:19

It looks like the only possibility to make this crash is vr::VRInput() is null [1], it is odd and only happened at one install, I will keep an eye on it.

[1] https://hg.mozilla.org/mozilla-central/annotate/adc59d50adf815ad6764ff235f833a5ba74291b6/gfx/vr/service/OpenVRSession.cpp#l820

Assignee: nobody → dmu

I think we should check if vr::VRInput() is null and its EVRInputError. Then, ask for Shutdown().

This patch should resolve this issue, but I would like wait for Bug 1564203 be solved to make sure there is no other regression.

Pushed by dmu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/96baa229787c
Checking if OpenVR vrinput() is null when doing initialization. r=kip
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Does this patch need a Beta approval request?

Flags: needinfo?(dmu)

Comment on attachment 9076625 [details]
Bug 1562679 - Checking if OpenVR vrinput() is null when doing initialization.

Beta/Release Uplift Approval Request

  • User impact if declined: This crash of OpenVRSession::SetupContollerActions will continue to happen.
  • Is this code covered by automated tests?: No
  • 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): This is a right fix for the OpenVR runtime stability. For some users, the VR input API is not ready yet when the VR system is trying to launch. We would like to give it a early return and ask for retry rather than this crash.
  • String changes made/needed:
Flags: needinfo?(dmu)
Attachment #9076625 - Flags: approval-mozilla-beta?

Comment on attachment 9076625 [details]
Bug 1562679 - Checking if OpenVR vrinput() is null when doing initialization.

Fixes a WebVR crash. Approved for 69.0b5.

Attachment #9076625 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.