OpenVR C# API crashes on compositor Submit after reinitialization

[glopesdev]

I have recently updated a demo project to the new OpenVR C# 1.2.1 (OpenVR 1.0.6) and I am now seeing memory access violations when calling compositor Submit but ONLY after reinitializing the system a second time on the same process.

Specifically, after the first Init things work fine and I can render everything and work with the system exactly as before. However, eventually I need to call Shutdown (for system cleanup reasons).

Now at some point in the demo logic I need to initialize the VR system again (i.e. by calling Init a second time), but this time I will get a memory access violation immediately as soon as I call Submit on the compositor.

Did anything change regarding the behavior of Shutdown that might be causing this behavior? I would say this looks like some dangling pointer that got left out somewhere and doesn't survive the Shutdown call.

Interestingly, all other API calls work exactly as before and the system is totally fine as long as I don't call Shutdown: only Submit crashes with a memory violation. Also, if I use the exact same code with the previous API, I can call Init/Shutdown as many times as I want on the same headset (same firmware), so it looks like something specific to the API and not related to some hardware/driver update, etc.

[bddckr]

I have a feeling you wanted to submit this issue to the OpenVR repo instead: https://github.com/ValveSoftware/openvr/
This repo is for the SteamVR Unity plugin.

[glopesdev]

@bddckr Thanks for the fast feedback. As a matter of fact, I just fixed it and it looks like it was indeed related to the C# API provided here (openvr_cs.api), although I still have no idea what caused it...

I had updated to OpenVR 1.0.6 a couple of weeks ago, but actually didn't notice at the time that this repo was itself only updated 2 days ago!

After posting the issue I noticed the recent commit, updated the C# API file and there you go, the problem was gone. No idea, but maybe some of the delegate references used by the wrapper got misdirected between versions of the native API... anyway, it seems to be solved, so I am closing this issue.