osvrUnityRenderingPlugin crashes Unity

[demonixis]

Hi,

I'm using the lastest OSVR SDK for Unity and I have random crashes with Unity so I've decided to try to debug Unity when it crashes. It seems that the rendering plugin has a problem and crashes Unity.

Logs

Le thread 0x2aec s'est arrêté avec le code 0 (0x0).
Exception non gérée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

Exception levée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

Le thread 0x1970 s'est arrêté avec le code 0 (0x0).
Le thread 0x2b78 s'est arrêté avec le code 0 (0x0).
Le thread 0x204c s'est arrêté avec le code 0 (0x0).
Exception non gérée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

Exception levée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

Exception non gérée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

Exception levée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

Le thread 0x28bc s'est arrêté avec le code 0 (0x0).
Exception non gérée à 0x00007FFDB31E29D1 (osvrUnityRenderingPlugin.dll) dans Unity.exe : 0xC0000005 : Violation d'accès lors de la lecture de l'emplacement 0x0000000000000100.

My configuration

• Windows 10 stable and updated
• Nvidia GeForce 980 with latest drivers
• Latest SDK / Core

[jfrank-razer]

This is completely reproducible on both of my development machines. One is a Razer Blade laptop with a GTX 870M and another is a custom desktop with a GTX 1070. Both have i7s and plenty of RAM.

Steps:

• Create a new 3D project
• Create an empty scene (or remove all objects from the current scene)
• Import the OSVR plugin
• Drag in the ClientKit and VRDisplayTracked prefabs
• (Note that the ClientKit defaults to having the Auto Start Server box checked)
• (Don't run the server)
• Click play
• (Observe the game preview window show one frame of your game, and then see the whole Unity editor environment crash)

The ClientKit defaults to having the Auto Start Server box checked, and unless you uncheck that, it crashes the whole Unity editor environment every time on both of my machines, losing unsaved changes to your scene.

Please let me know if I can provide any further diagnostic information. The debug trace above (in French) appears to be the equivalent to the one I see in English.

[DuFF14]

Which version of the server are you using? The auto-start bug was fixed a couple months ago, I don't remember which version exactly. Any of the recent builds from here should work: http://access.osvr.com/binary/osvr-sdk-installer
I can't reproduce it, but used to see it on old servers.

[jfrank-razer]

@DuFF14 I believe I'm on version 1337/build 329 at the moment. I assume that's an auto-incrementing version number from CI builds and is based on whatever's in OSVR-Runtime-v0.6-1337-g9292631-build329-win-64bit.msi. For some reason, access.osvr.org doesn't have publishing dates on it and searching for 1337 and 329 doesn't come up with anything on ci.osvr.org, so I'm not sure how recent it actually is.

If it's not too much trouble, could you point me to the commit, version, build, etc. that you think that bug was fixed in? In the meantime, I'll try to find some time verify that it's fixed for me with a more recent version of the server.

[jfrank-razer]

This crash also seems to occur if the box isn't checked and the server isn't running.

I confirmed that this crashes with the following versions (note that I'm using the Runtime rather than SDK installers):

• OSVR-Runtime-v0.6-1337-g9292631-build329-win-64bit.msi (it worked once then crashed all the time)
• OSVR-Runtime-v0.6-1339-g3139e8c-build332-win-64bit.msi
• OSVR-Runtime-v0.6-1341-g0cae009-build337-win-64bit.msi (this is the latest release)

I'll try restarting etc.; it's possible I'm seeing a transient issue and uninstalling and reinstalling each of those versions didn't reset the relevant state.

I'm on Unity 5.4.1f1 and Win10x64 + AU.

[DuFF14]

I think the auto-start crash bug was fixed with this PR: OSVR/OSVR-Core#467

[jfrank-razer]

@DuFF14 Interesting. Do you know which Runtime MSI release contains that fix? Also, is there any reason to think that installing the SDK will do something different than the Runtime with respect to the OSVR Server?

[DuFF14]

I think all of those you listed contain the fix. Runtime shouldn't be any different. Also check your OSVR_SERVER_ROOT environment variable and make sure its set to C:\Program Files\OSVR\Runtime\bin\

[jfrank-razer]

@DuFF14, the environment variable is set correctly. I imagine it doesn't matter that I installed to C:\Program Files\Sensics OSVR v1341\Runtime\bin\ rather than the default.

Suspecting some cross-talk between the different installers, I just tried it on a machine that never had anything on it from the All-in-one Windows installer and it's still happening, but that machine is setup with the older OSVR-Runtime-v0.6-1320-gc0575b0-build260-win-64bit.msi and OSVR-HDK-Combined-Driver-Installer-1.2.7.exe. It's not crashing if the server isn't running and the box is checked there though. I'll try it with a newer version and get back to you.

[DuFF14]

I think auto-start opens the server in the default path, so that's the one that should be updated to fix the bug. You could change the environment variable to C:\Program Files\Sensics OSVR v1341\Runtime\bin\ to test.

[jfrank-razer]

@DuFF14 Sorry, I wasn't clear; my bad. It is set to that path:
OSVR_SERVER_ROOT=C:\Program Files\Sensics OSVR v1341\Runtime\bin\

I'm updating Unity and will then try the most recent Runtime installer from access.osvr.org in my clean environment. I'll get back to you.

[jfrank-razer]

@DuFF14 - The plot thickens. It seemed okay in my clean environment with the latest Runtime installer (1341), Unity, and OSVR Plugin, so I went back and installed v1337. It crashed in v1337 initially several times in a row, but after I ran OSVR Server manually myself on a whim and then tried again, it stopped crashing. Now, no matter which one I uninstall and reinstall, it's working, even after reboots. That certainly accounts for why it's so hard to reproduce for your team.

The reason I've been so interested in this bug is that we wanted to know whether the OSVR Core version we're distributing with our upcoming Windows installer release has a bug that's since been fixed. Given the number of variables in play, it doesn't seem like there's any way to tell. Because of that, actively investigating this won't be my top priority anymore, but I'll be sure to post back if I find any more information.

Thanks so much for your patience and responsiveness! I really appreciate it.

[DuFF14]

@jfrank-razer thanks for the info. I'm pretty sure the auto-start bug was fixed after Core v12xx, but there might be one or two builds of v13xx that have the bug. @rpavlik might have a better estimate.

[DuFF14]

Looks like the commit that fixes the bug has hash 929263, which correlates with OSVR-Core-Snapshot-v0.6-1337-g9292631. So v1337 or newer should be good.

[jfrank-razer]

@DuFF14 Awesome, thanks so much for tracking that down for me! =)

[DuFF14]

Should be fixed in #34