File descriptor exhaustion after repeated Unity Editor start/stop

[MariusGr]

Describe the bug
In Unity Editor 6000.4.3f1, with Ultraleap Tracking 7.3.0 installed in a project, after starting and stopping play mode a few times, this error occurs:

Unhandled exception during build: System.NotSupportedException: Could not register to wait for file descriptor <file descriptor number>

The number at the end is usually something between 1000-1200. It seems like something in Ultraleap leaks open file descriptors. The number increases with each start and stop of the play mode until the number of open file descriptors for the Unity process exceeds 1000. From this point on, the exception above occurs sometimes during play mode, and sometimes during edit mode. In any case, it prevents starting another play mode since Unity recognizes this as compilation error and refuses to play.

If it occurs during play mode, other functionalities sending SocketIO messages in my project do not work anymore. Thus, I suspect that something regarding Ultraleap's connection attempts to the Tracking Software might be causing this.

As of now, the only workaround for this is to close the Editor and open it again as this resets the open file descriptors.

To Reproduce
Steps to reproduce the behavior:

1. Open a completely new Unity project with "Universal 3D"

2. Start & Stop play mode once

3. Execute in terminal
   lsof -n | awk '{print $1}' | uniq -c | sort -rn | head -n $LINES
   You will see an entry with title "Unity" and some number around 200-300. This is the number of currently open file descriptors for Unity.

4. Start and stop the play mode a few times. Then, execute the command again. You will see no increase in that number.

5. Install Ultraleap Tracking 7.3.0 via the Package Manager.

6. Retry step 5. Now, you will see an increase of the open file descriptors, which should be roughly 20-40 for one start & stop of play mode.

7. Repeat until the number reaches a value above 1000 and a few times more, then you should get the exception mentioned above.

Project details

• Unity version: Unity Editor 6000.4.3f1, also encountered in 6000.3.11f1
• Plugin/package version: Ultraleap Tracking 7.3.0
• Installation method: OpenUPM
• Packages affected: Ultraleap Tracking

[rblenkinsopp]

Thank you for reporting this issue, I've just been able to also reproduce it (on macOS) and will investigate further. Can I double check which platform you are seeing this on?

[rblenkinsopp]

Could you see if this PR helps with this issue: #1713

It resolves it for me in my testing.

[MariusGr]

Thanks for the quick response.

Unfortunately, your PR does not fix the bug in my machine.

Target platform in Unity's build profile is macOS, same as the operating system of my machine (macOS on Apple M1 Max).

What I did to test your PR:

• Pull repo from https://github.com/ultraleap/UnityPlugin.git
• Checkout branch rcb/connection-rework
• Uninstall UltraLeap UnityPlugin from my project via PM
• From the cloned repo, copy Packages/Tracking over to my empty projects Packages folder
• Restart Unity Editor

I then reproduced the bug by repeatedly starting and stopping play mode, where I could, again, see the number of open file descriptors for Unity rising. At 1207, I again got the known error message: "NotSupportedException: Could not register to wait for file descriptor 1065".

Still, uninstalling Ulrealeap from my project prevents this from happening.

Would you suggest a different way to test your solution?
Did you test your solution on an Intel or Silicone Mac?
What Unity Editor version did you test in? This bug does not seem to appear in older versions than 6000.xx.

[rblenkinsopp]

You are correct that it doesn't appear to resolve it after all, I believed it did because I managed to play/pause many more times than the first time I saw the NotSupportedException, but more direct inspection with lsof shows it's not resolved.

Your testing methodology is correct and is exactly what I'm doing here (on a M2 Max, Unity 6000.3.14f1). I'm going to attempt to do a bit more tracing today but if I don't get to the bottom of it today, I'm away for the remainder of the week so I won't be able to look further until next week.

[rblenkinsopp]

I've done some more investigation on this today, and I believe the issue is actually in the native LeapC library. I've done some provisional work on fixing this but I've not completed it yet I'm afraid. That will also have a slightly longer release cycle to get it into the plugin but I'll resume work on this when I return.

[rblenkinsopp]

I've located the issue and fixed this in the underlying LeapC library, we will have to run this through our internal release proceedures before I can update the .dylibs in this plugin but the issue is resolved will be released hopefully shortly :)