I’ll write a few things here about the problem which has been plaguing our CI Jenkins and our macs for some time now, crashing Unity before it even opens.
Basically Macs can’t run process that use many files/many processes/many files per process/many processes per uid
basically because of that, as Unity tries to access the next file, say a dll or a shader it crashes and the error says something random like “thread crashed” or “shader compiler failed” basically leading us to random conclusions.
Some useful commands that I have used to see the problem ( but still no solution )
shows you current limits: ulimit -a
turns on server mode to boost performance: sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"
shows processes that use most files: sysctl -a | grep ^kern.max
edits maxfiles usage till next reboot: sudo launchctl limit maxfiles 204800 204800
you can edit max limits on startup for a Mac creating a sysctl.conf ( latest OSs ) on the /etc/ folder with the following settings:
apparently each mac depending on it’s specs ( one mentioned based on RAM ) have different max limits but even though I’ve managed to edit them all the problem still appears at around 1700 files.
Anyone that has managed to solve this please give us a hand <3
Seems to be FileSystemWatcher which is a tool by Microsoft. It’s normally a 4k buffer but now appears to be 8k by default. You can set it in code to increments of 4k but no higher than 64k. If it loads too many files in too short a time then it overwrites its buffer and crashes! This is obviously trash software but hey it’s free. Also Unity claims to fix it in 2022.1.0a12 but, nope, it still fails [Unity 2022.1.0a12 macOS: Fixed Unity shader compiler crashing on macOS Monterey when using Apple silicon editor. (1361979)] Fails on my M1 Max 64gb memory with 2tb SSD.
I also upped all of the mayflies and other nonsense that’s really low to no effect.
It really seems to be something in FileSystemWatcher and it’s in several packages such as JetBrains Rider (removable from Unity Registry), PlasticSCM (not removable), and some Lump libraries.
It also only happens on import for macOS (Monterey or other versions) where it doesn’t need to use FileSystemWatcher as, according to others, it’s only needed for Windows. It also seems to happen when you have around 100+ assets.
Works fine up to version Unity 2021.1.28 but anything from 2021.2 or 2022.0 fails on import.
Still seeking a solution as well. Currently stuck on 2021.1.28.
This has been a really bad issue for me as well, and every solution that i can find online doesn’t seem to apply for the M1 Macs running Monterey. It looks like i can get MacOS to tell me the file limit is raised, but when it actually comes down to opening a project it still fails.
I’m unfortunately stuck on Unity 2019.4.x
I’ve had to abandon projects and the new ones that i’m starting i feel as if they’re on a time limit until i can’t use them anymore.
@zdragon5556 interesting that it’s a problem even with M1 Macs, I was hoping to buy a new mac and test whether the issue persists. That’s terrible for every big project.
This is the inverse of what I would expect. The last time I looked into this bug it was an issue with the older version of mono used in Unity versions prior to 2021.2 as referenced in the bug you linked. Have you submitted a bug for your case? This is unexpected and I would like to investigate to see if I can figure out what’s up.
Ok good to know. If either of you have a bug number that has a repro project attached I can investigate to see what’s going on. The project that I have works fine on my m1 and intel macs.
I’ve lost mine over the years but the question is whether your project has a lot of files in, like a full production project type of size 30k files for example
I can’t share it but I imagine it should be easy to reproduce if it has to do with the amount of files regardless of what type they are. Making a console application that generates thousands of cs files inside assets and try to open it later.
Take a look at it as soon as you can because from QA they have answered me and as you will understand, it is not the answer I expect since the person who has reviewed it has not even noticed that I am reporting it in a version higher than the one that mentions that issue as fixed.
Hello, after looking into this matter and testing it, I have found that in 2021.3.6f1 it doesn’t crash anymore, I also didn’t encounter any crashes, also one thing that I noticed, that after opening the project in 2021.3.6f1 and then opening it in 2021.3.5f1 the project opens as it should.
Yes I tested it on mac, and I did try to open the project several times on different versions of Unity, and on 2021.3.5f1 it would only crash consistently only if I tried to open it only with 2021.3.5f1 without trying newer versions before. But otherwise, I couldn’t get crashes on other versions other than 2021.3.5f1 with the project that you attached. Could you try to reproduce this with newer Unity versions on your machine and see if it crashes
@Alex-Thibodeau makes sense what @KaroCerv says? I mean, in 2021.3.6f1 has something been modified that may have fixed this problem? Because reading in changelog, it doesn’t seem so.
Personally I haven’t tested to open it in 2021.3.6f1 (I’ll test it and let you know) but it sounds weird to me for that reason.
It’s possible that the issue you were seeing was not a result of running out of file handles on MacOS and was instead being caused by some other issue. I haven’t yet had time to debug your project myself so I don’t know for sure what the root cause is. Please let me know how the newer version works for you.
)
<3