1342430 - Crash in libovrrt32_1.dll@0x1e1bf

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Julian Seward [:jseward]]

This bug was filed from the Socorro interface and is 
report bp-76807116-eff0-4cd7-b03c-b1e6b2170224.
=============================================================

This is ranked #16 in the crashes for Windows nightly of 20170223030204.
It's not a high volume bug, but there are three different reports all
of which mention VRDisplayOculus.

Comment 1

[:kip (Kearwood Gilbert)]

Thanks for reporting this.

It is indeed Oculus VR related.  "libovrrt32_1.dll" is part of the Oculus runtimes.

I suspect that this may be happening on the GPU process when the content process shuts down unexpectedly and VR presentation is active.

I'll investigate further.

Comment 2

[Nicholas Nethercote [inactive]]

#11 Windows topcrash in Nightly 20170224030232.

Comment 3

[:kip (Kearwood Gilbert)]

I think I see what is happening in this case.  This might to be happening if the content process dies during VR presentation.  The line that is causing the crash is attempting to submit a final black frame to cover any content that would persist in the headset, but the VR session is likely no longer valid as things are being destroyed.  I can pass a value in for this call stack to skip the black frame submission.

These also appear to be happening more often on 32-bit builds..  Perhaps the content process is hitting OOM due to fragmentation and this is happening afterwards...

I'll make a patch as described.  Hopefully this will help, but should have no negative effects if my hypothesis is incorrect.

Comment 5

[:kip (Kearwood Gilbert)]

I have received reports from Oculus that their telemetry is showing Firefox being killed due to holding on to the Oculus runtime DLL's during their software update process.  This could be the cause of many of these GPU process shutdowns.

Comment 6

[:kip (Kearwood Gilbert)]

I have cleaned up our Oculus implementation in Bug 13351048 to handle sessions better.

I found that it was no longer necessary to submit a black frame at the end of the session and have eliminated it in the cleanup.

Additionally, I now unload the Oculus runtime library when possible and avoid loading it until the user hits a WebVR page.  This should hopefully reduce the incidence of hitting this crash.

To fully correct this; however, we may need help from Oculus, who has been willing to review our implementation.  I suspect that we need a better mechanism to allow Oculus to detach from the browser without shutting down the browser process.

Comment 7

[:kip (Kearwood Gilbert)]

I suspect that this crash will go away once Bug 1352446 lands.

In Bug 1352446, I found a mismatch of our declaration for the ovr_SubmitFrame function and the implementation in the Oculus dll.  This crash also involves ovr_SubmitFrame and is likely the same underlying cause.

Comment 8

[:kip (Kearwood Gilbert)]

This crash would have occurred in cases when a site entered VR, did not submit frames, and then existed VR.  It has the same root cause as Bug 1352446, which as now landed.

Comment 9

[:kip (Kearwood Gilbert)]

Note that I have requested uplift to Beta in Bug 1352446, which should fix this for Beta as well.