Once I figured that out and that the memory was being exhausted because too many build jobs were being kicked off, I thought it was cmake itself passing the -j14 flag to ninja. It wasn't until later that I realized the crashing was caused by running out of memory. I thought that was the issue (and I'm sure it plays a role).
CMAKE VISUAL STUDIO MULTI JOBS SOFTWARE
Whenever I would kick off a build the IT mandated anti-virus software would go "nuts" (briefly spin two processes up to like 400% cpu utilization). This problem had been plaguing me for a couple of weeks-first it wasn't obvious that I was running out of memory.
The problem is that it's not obvious that it's cmake-tools that's invoking non-default ninja behavior and that that's what what causing all of my memory to run out. Using the flag was easy enough once I figured out what the issue was and once I knew about the flag. Hope this makes sense, let me know if I can help somehow. I'm quite certain by now that this is the cause of the issue, as I've been digging into it for months and it always happens when building a CMake project via VSCode and this extension. (Ninja appears to honor the last -j argument on the command line, so I can work around this temporarily by setting buildToolArgs to something like in my user preferences, but that would break as soon as I set build tool args in a workspace for any reason - fortunately unlikely.) There's already a setting for build args and build tool args, so users could override (presumably per-workspace) job counts if they wanted something less than max parallelism. The line I pointed out above could be modified slightly to just not pass the jobs argument to ninja generators. Additionally, it's somehow more efficient than make, so specifying the "little bit more than the cores" value that works with make ends up overwhelming systems (I've done this on Windows too, even with more RAM). When building with Ninja, even via cmake -build, it automatically defaults to "maximum parallelism", so passing -j 18 is unnecessary to get parallel builds.
I suspect it has to do with the fact that this extension calls cmake -build passing -j 18 on my 16-thread machine. I can sometimes get in via a virtual console or ssh, which usually reveals that something prompted running out of memory (swap is somehow uselessly slow) or something else.
CMAKE VISUAL STUDIO MULTI JOBS CODE
I can use Ninja on its own just fine, but probably at least once a day, if I build within VS Code via this extension, X.org will stop responding. I use Linux and am frequently close to nearly-out-of-memory. I have a RyZen 2700x (8 core, 2thread/core, so 16 logical cores).
0 kommentar(er)
