OpenVR XR Plugin 1.0.1 Crashes Editor on Initialization (in SetUserDefinedSettings)

[gavaga]

We have been dealing with an OpenVR XR Plugin crash bug for a while now, where we get a hard crash in the Editor (uncaught native exception) when OpenVR is initialized. It was initially observed in the XR Management RuntimeInitializeOnLoad sequence with the OpenVR plugin enabled for desktop, so we moved to initializing OpenVR and SteamVR from MonoBehaviour.Awake/Start in the scene, which seemed to resolve it, but that's now crashing, as well. It's not 100% consistent, but around 4/5 times we hit Play it crashes.

Observed on OpenVR XR Plugin 1.0.1, with SteamVR Plugin 2.6.0b4, editor versions 2019.3.6 and 2019.4.x. Never observed in a built Player.

Maybe duplicate, but the relevant issues I could find steamvr#716, steamvr#704 don't seem to have quite the same failure mode, and claim to be resolved in the versions we're using.

Relevant part of the stack trace (above this in the chain is MonoBehaviour.Start() on our loader GameObject):

Relevant section of Editor log: https://pastebin.com/SmY9LKGF

[hnguyen094]

We also noticed that the Editor crashes 100% of the time when we set OpenVR to Multi Pass, as some of the other relevant issue threads have discussed as a potential fix.
Here is the stacktrace from Editor.log: https://pastebin.com/ZsPfpZTh

[WBoode]

We are encountering the same issue.
Unity 2019.4.x (currently .10)
OpenXR VR version 1.0.1
SteamVR 1.14.16

[keithbradner]

I'm having trouble reproducing this, can one of you provide a simple example project? @WBoode @hnguyen094 @gavaga

[keithbradner]

Closed due to inactivity.

[CoderDawson]

@keithbradner I am actively running into this same issue right now with Unity 2019.4.16f1, Plugin 1.0.1, and SteamVR 1.15.12.

In my particular case the Unity Editor just "goes away", the Unity crash handler doesn't catch the issue, and no crash dump is generated. Unfortunately, I do not have a repro project yet as the issue is random most of the time.

I connected the Visual Studio debugger to Unity to see if I could get any extra information on what was occurring and with the debugger attached the Unity Editor doesn't die at all but it triggers two break points in the ntdll.dll with exceptions regarding heap corruption.

Looking at the SetUserDefinedSettings function in the UserProjectSettings.cpp code, I am hoping that the main part of the problem is the buffer overruns occurring when copying the editorAppKey, actionManifestPath, and/or appName strings where the buffer is allocated using strlen but the strcpy is using strlen + 1.

[CoderDawson]

@keithbradner I made the buffer overrun fixes locally and I no longer seem to be able to duplicate the Unity dying issue after many multiple enter and exit playmode attempts. Let me know if commenting on this issue is enough or if you need me to make a new issue to get the fix in.

[keithbradner]

Can you verify that you're getting the right number of characters for those variables (like does the app name show up right in steamvr) I was under the impression the +1 accounted for the null terminator.

[CoderDawson]

The +1 in the strcpy call is correct to include the null terminator. The problem is that the buffer was allocated using the value return by strlen, which does not include the null terminator in the count. This results in the strcpy call writing one byte passed the end of the buffer. The fix is to add a +1 to the strlen result when the buffers for the strings mentioned above are allocated.

However, I will confirm the character count and SteamVR display in the morning if you feel it is still necessary.

[CoderDawson]

@keithbradner I have confirmed the character count and SteamVR display is correct when entering playmode with the fix to increase the allocated buffer size by one to match the strcpy call size.

[CoderDawson]

@keithbradner This pull request has my proposed changes: #72

[OwlchemyDawson]

Make that pull request #73.

[OwlchemyDawson]

@keithbradner Is there anything further I can provide to get this issue resolved?