pushrax / OpenVR-SpaceCalibrator

Use tracked VR devices from one company with any other.
MIT License
669 stars 111 forks source link

Crashes when run with OwOTrack #50

Closed Mage-Enderman closed 3 years ago

Mage-Enderman commented 3 years ago

When using OwOTrack if this add-on is enabled it just crashes steamvr when you connect your phone to your computer If OpenVR-SpaceCalibrator isn't running it's fine Edit: it seems it's when you create a tracker not when you connect your phone

pushrax commented 3 years ago

Might not be too hard to fix, since the OwOTrack driver is open source here https://github.com/abb128/owo-track-driver

I don't see anything wrong after a quick read over the code. I can't guarantee any particular date to reproduce and debug this myself. I don't have an Android phone.

abb128 commented 3 years ago

I don't have an Android phone.

From the reports, the crash seems to happen not when the Android phone connects, but rather when the tracker is spawned. An Android phone should not be necessary to replicate this issue. I have not looked into this issue yet, but I will try to look into it from my side as well, when I have more time to work on it.

abb128 commented 3 years ago

I have nailed down the cause of this issue.

Without OpenVR Space Calibrator running, the Activate method of a ITrackedDeviceServerDriver appears to get called immediately after the device is added through TrackedDeviceAdded.

However, this does not appear to be the case with OpenVR Space Calibrator running, and there is at least one frame where RunFrame of my device provider gets called BEFORE the device has had the Activate method called. This prompts a crash, because I had assumed it would already have been activated by then.

This has been fixed in https://github.com/abb128/owo-track-driver/commit/b72cf1d70715c76e38cfedc1a52887f58b2e5b1a

pushrax commented 3 years ago

Thank you @abb128!

I believe there's no interface contract that guarantees an added TrackedDevice is immediately activated.

https://github.com/pushrax/OpenVR-SpaceCalibrator/blob/f3b4f9475e70a7c84bd84ee1851ab980e758d6b9/lib/openvr/openvr_driver.h#L3399-L3402

This implies it will be activated... at some point in the future.

I'm not too sure why Space Calibrator would affect this, as it only hooks IVRServerDriverHost::TrackedDevicePoseUpdated and IVRDriverContext::GetGenericInterface. There may be some kind of race condition that's exacerbated by the GetGenericInterface hook, or maybe just some difference in server behavior depending on driver load order. I could be missing something though.

I haven't heard of any issues with this other than with owo-track, so I'm going to close the issue, and keep an eye out for similar issues in the future. The context you provided here is very helpful.