Steps causing the bug to occur
- Add NDI input
- Scale the NDI Input
- Send it to an NDI output
- Repeat 7-8 times
- Export as an app (or open the attached app)
- Run app and observe crash with apparent cause “Too many open files”
Have you found a workaround?
No.
Other notes
- Vuo version: 2.2.1
- macOS version: macOS 10.15
- How severely does this bug affect you? It prevents me from completing a specific task with Vuo.
Seems to be related to the amount of I/O when exporting as an app. Using an exported app with 2/4/6 I/O works. Opening another instance/app increasing the total I/O to above 6 (or 7, haven’t tested that) will crash it. I am not surprised it crashes when scaling 8x NDI inputs from a resource standpoint. However, this is without any sources present so there shouldn’t be any load generated from a video processing perspective. I’m more surprised by the error message it produces:
terminating with uncaught exception of type std::__1::system_error: kqueue: Too many open files
I haven’t actually tested this with more than 1 NDI In/out. Crash is consistent without having active sources. Running the composition inside Vuo does not crash.
8NDI_resizer_2021-03-19-120359_1234.crash (157 KB)
8NDI_resizer.zip (3.28 MB)
The operating system imposes a limit on the number of “files” that a process can open. “Files” includes not only regular files but other things like network sockets, pipes, and the “kqueue” mentioned in the error message.
Each NDI send/receive node adds to the number of open “files” — because of course it needs those to be able to communicate with other nodes or devices.
The reason your composition doesn’t crash when run from the Vuo editor is because we happen to have already increased the number of open files it is allowed (to fix a different problem). To resolve this bug report, we’ll similarly increase the number of open files allowed for exported apps. That will fix your crash.
As a workaround until then, you can run this command in Terminal to increase the number of open files allowed:
sudo launchctl limit maxfiles 1024 unlimited
(This is a system-wide setting, affecting all processes and not just your NDI app. It will reset after you reboot, unless you do more work to make it stick.)
1 Like
Thanks for the explanation! Does this mean that the Vuo Composition Loader runs as one process when two or more exported apps are running though? As two different applications with 4 I/O each also will crash? Or could this be because of app/composition naming (not sure if I was particularly careful there)?
VuoCompositionLoader only comes into play when running a composition from the editor. When you run a composition, Vuo spawns a process called VuoCompositionLoader. VuoCompositionLoader is a middle layer between the editor and the composition that makes live editing possible. As you can see in Activity Monitor, a separate VuoCompositionLoader process is created for each running composition.
When you run an exported app, there’s no editor or middle layer, just a process for the composition itself. As Activity Monitor shows, there’s a separate process for each app (even if they have the same name).
Since the limit on open files is per-process, you should be able to split your 8-NDI app into 2 x 4-NDI apps and avoid the crash… Yep, I tested and it seems to work.
Thanks! Previously when i ran above 8 I/O split into separate apps it crashed. I assumed it was related to the same issue but trying again now it seems to work.