Windows: openvr.init never release memory
mann1x opened this issue · comments
I'm using Windows 10 1903 with Python 3.74 and SteamVR beta 1.8.12, pyopenvr 1.7.1501.
Memory allocated by the openvr.init call is never released.
It's allocated either if the call is successful or not.
Deleting the object or forcing garbage collector didn't help either.
@mann1x I assume you observe it on the same script you used in #70 (https://github.com/cmbruns/pyopenvr/files/3723923/testloop.txt), even after fixing the access violation issue.
How do you measure the leak? Do you use Python memory profiler, or a native code one?
It can be observed visually also with process hacker if the loop is very tight.
I used print_diff() from tracker.SummaryTracker() to print the memory allocated and gc.collect() every now and then to see if it could recover it.
@risa2000 Sorry I didn't check with tracker there. I used it in the main script.
If the loop just tries to allocate vr_system with the init the python process grows constantly.
I just started the script from issue #70 and went from 31 MB to 63 MB in 5 minutes.
If the init fails then vr_system object is never created so I cannot delete it.
The difficulty here is that opevnr.init() is just a wrapper to call a native init, which among other things dynamically loads vrclient_x64.dll, initializes it and gets IVRSystem interface which is then "pythonized" and passed to the client code. So my suspicion is that it is the DLL (init and/or detach) which leaks the memory.
Knowing if the memory leak comes from the Python code or the native one would help, and I was hoping that you might be able to verify it on your code.
Added tracker and the diff is always empty.
I guess it's the native DLL, here's the memory profiler output:
Line # Mem usage Increment Line Contents
22 39.414 MiB 38.992 MiB @profile
23 def init_vr():
24 39.555 MiB 0.270 MiB vr_system = openvr.init(openvr.VRApplication_Background)
Let me know if there's something else I can do.
I have submitted an issue on OpenVR repo (ValveSoftware/openvr#1221).
So this is apparently a known issue since 2016 (ValveSoftware/openvr#195). I am not sure what to think, but not much can be done here.
Real pity, thanks for your support! I'll ping on the original issue