Otter-Co/TurnSignal

Memory leak when SteamVR is not running

Closed this issue · 14 comments

If TurnSignal.exe is launched manually (I understand this is not the typical use case) while SteamVR is not running, the memory usage seems to increase by roughly 1-3 MB per second indefinitely. I saw it reach as high as 2 GB before I ended the task, and at that point the CPU usage had also increased quite a bit (~8% when it's typically under 2%).

OS: Windows 10
Processor: i7-6700K
RAM: 16 GB
GPU: EVGA 1080 Ti Hybrid
Tested release: 2.0

Heya, thanks for the bug report!
This is a strange issue, I had something similar reported in 1.x, but this is also a test case I did not run either time! (I have kept it running all the time to stress test it, but always booting it with SteamVR)

It must be how I'm initializing OpenVR, or checking for its presence or something,
I will look around there.

Upon further investigation, it turns out its a memory leak in the Native OpenVR (1, 2, 3) Init handler.

While so far I can't really find a way to deal with this, I will keep investigating!

After doing some experimentation, it looks like the SteamVR plugin is outdated and uses outdated OpenVR .dll, manually copying in the newest 1.0.9 SEEMS to have alleviated the issue, if i its an asap problem for you, I'll push out a new build very soon with the newest libs!

It's not an ASAP problem for me; I just had it running so that the next time I started SteamVR I could try it for the first time. Thanks for working on this and finding the fix so quickly. Take your time with the update, and enjoy your weekend!

Fixed in 3f3e4d6
Bam, Newest Release (2.1 at this time) under releases! Let me know if this helps / fixes your issue!

Hey, @benotter. Looks like this one's not quite solved yet. I'm still seeing an increase of about 0.5-1 MB per second, which is at least an improvement. I notice that it's constantly writing to a log file (C:\Program Files (x86)\Steam\logs\vrclient_TurnSignal.txt) which only contains the following section, repeated every ~110 milliseconds (two iterations shown):

Sat Jul 29 2017 14:12:13.122 - //=====================================================================================================================
Sat Jul 29 2017 14:12:13.122 - vrclient startup with PID=5952, type=VRApplication_Background, config=C:\Program Files (x86)\Steam\config
Sat Jul 29 2017 14:12:13.123 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.124 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\htc\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.125 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\lighthouse\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.125 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\null\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.125 - [Settings] Load Json Settings from C:\Program Files (x86)\Steam\config\steamvr.vrsettings
Sat Jul 29 2017 14:12:13.127 - Not starting vrserver for background application.
Sat Jul 29 2017 14:12:13.233 - //=====================================================================================================================
Sat Jul 29 2017 14:12:13.233 - vrclient startup with PID=5952, type=VRApplication_Background, config=C:\Program Files (x86)\Steam\config
Sat Jul 29 2017 14:12:13.234 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.234 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\htc\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.234 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\lighthouse\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.234 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\null\resources\settings\default.vrsettings
Sat Jul 29 2017 14:12:13.235 - [Settings] Load Json Settings from C:\Program Files (x86)\Steam\config\steamvr.vrsettings
Sat Jul 29 2017 14:12:13.236 - Not starting vrserver for background application.
Sat Jul 29 2017 14:12:13.342 - //=====================================================================================================================

image

Not sure if that helps. Let me know if I can get any other useful information to help you debug this.

Tested Release: 2.1.0

Huh, super weird!

I tested under reproduced conditions, started it without steamVR and let it sit for a long while without starting it, never climbed up beyond 75mb for me, so I guess unable to reproduce, but this is also a known issue in the OpenVR api where calling Init causes leaks on failure, even when you force a cleanup,

I'm not sure quite how to fix this, so I will leave it open, and keep looking for a solution, but I need to find one until I fix issues with auto-start on SteamVR

Perhaps you can try to first detect the presence of SteamVR's running process before starting to call OpenVR's Init?

Thats is sort of what the OpenVR init actually is, you call it so see if there is a running instance of openvr, and depending on application type, it will either start up steamvr, or just fail with whats supposed to be essentially 'VR's not Running, background apps are not the type to start it either', and it does fail but as a bug in openvr, it doesn't clean up its initially spawned threads for the work its expected, or at least, that's what I've read about and seen as much in memeory debugging.

Which is why a pre-check should be performed to minimize their bug. Just a simple System.Diagnostics.Process.GetProcess("SteamVR.exe").Exists or whatnot before calling init. I'm wiring this from my phone, so it won't actually compile, its just pseudo code.

@Allon-Guralnek That is actually not a bad idea, I will see if I can test that snippet, or find something similar!

@Joe-Klauza Heya, did a few commits, and since #14 , I added a check for vrserver based on @Allon-Guralnek 's suggestion! Thanks @Allon-Guralnek !

Let me know if its better or worse, and if you guys think its a viable fix!

image

Looks like it's all good now memory-wise! I notice that it's using between 1-2% of my CPU constantly when SteamVR isn't running. Assuming you haven't already, is there any chance you can add a sleep for a few seconds between every check so as not to use more CPU than other idle applications? We can handle it in a new issue if you'd prefer.

Tested release: 2.1.2

Heya, glad it looks like the leak seems solved!

And as far as the CPU usage goes, I would really appreciate if you threw it in a new issue, and I will look into getting unity to sleep between VRServer checks!