OpenSpace builds on Github actions getting "terminated" - exit code 143

Some of my build github action workflows were consistently getting terminated after 10 minutes of run time or so. 

gmake[2]: *** Waiting for unfinished jobs....

gmake[2]: *** wait: No child processes.  Stop.

gmake[2]: *** [ext/spice/CMakeFiles/spice.dir/build.make:3607: ext/spice/CMakeFiles/spice.dir/src/common/dafopw_c.c.o] Terminated

gmake[2]: *** [ext/spice/CMakeFiles/spice.dir/build.make:3635: ext/spice/CMakeFiles/spice.dir/src/common/dafps_c.c.o] Terminated

gmake[2]: *** [ext/spice/CMakeFiles/spice.dir/build.make:3663: ext/spice/CMakeFiles/spice.dir/src/common/dafrcr.c.o] Terminated

gmake[2]: *** [ext/spice/CMakeFiles/spice.dir/build.make:3649: ext/spice/CMakeFiles/spice.dir/src/common/dafra.c.o] Terminated

gmake[2]: *** [ext/spice/CMakeFiles/spice.dir/build.make:3691: ext/spice/CMakeFiles/spice.dir/src/common/dafrda_c.c.o] Terminated

gmake[2]: *** [ext/spice/CMakeFiles/spice.dir/build.make:3565: ext/spice/CMakeFiles/spice.dir/src/common/dafgsr_c.c.o] Terminated

gmake[2]: *** [modules/globebrowsing/ext/geos/CMakeFiles/geos.dir/build.make:2514: modules/globebrowsing/ext/geos/CMakeFiles/geos.dir/src/io/StringTokenizer.cpp.o] Terminated

Error: Process completed with exit code 143.

Gemini - via aistudio.google.com free plan - pointed out that 

Exit code 143 indicates that a process was terminated by a SIGTERM signal. In GitHub Actions, this almost always happens when the build runner runs out of memory (OOM) and the operating system or the GitHub runner agent terminates the compiler processes to save the system.

Compiling large C++ projects like OpenSpace with heavy submodules (such as Assimp/Draco, Boost, and Spicelib) using GCC 13 can easily exceed the 7 GB RAM limit of the standard GitHub-hosted runner, especially when building in parallel.

Here are the two most effective ways to resolve this:

1. Limit Build Parallelism

By default, cmake --build . --parallel attempts to use all available virtual CPUs. While GitHub runners have 2 vCPUs, compiling templates in parallel can still exceed 7 GB of RAM.

Limit the concurrent build jobs to 2 etc etc

So I changed 
 cmake --build . --parallel

to
 cmake --build . --parallel 3

like the workflow which was working, and that solved the problem. Told Gemini that, and the reply was,

You are correct. Standard GitHub-hosted runners for public repositories were updated to 4 vCPUs and 16 GB of RAM.

When you run cmake --build . --parallel without specifying a limit, it attempts to spawn 4 compilation jobs. With heavy C++ headers and templates, 4 concurrent GCC processes can still spike past the 16 GB memory limit, triggering the termination.

Limiting the build to --parallel 3 (or --parallel 2 if memory usage remains high) is a solid approach to keep the peak memory consumption within the runner's limits.

Then I asked Gemini,

Same codebase, same runner.
cmake --build . --parallel causes termination.
make -j $(nproc) does not cause termination, why?

Then Gemini changed the answer to specify that parallel without a number means unlimited parallel jobs - 

The difference lies in how GNU Make and CMake interpret the omission of a job

number.

1. cmake --build . --parallel maps to unlimited jobs

When you run cmake --build . --parallel without specifying a number, CMake

translates this to the underlying build tool's default parallel flag.

For GNU Make, this translates to running make -j (with no number). In GNU Make,

omitting the number instructs it to run with infinite/unlimited parallel jobs.

Instead of spawning 4 compiler processes (the number of CPU cores), it will try

to compile dozens of source files simultaneously. This immediately exhausts

the 16 GB of RAM and triggers the OOM killer.

2. make -j $(nproc) strictly limits the jobs

When you run make -j $(nproc):

1.  $(nproc) evaluates to 4.

2.  The command becomes make -j 4.

3.  GNU Make is strictly limited to running a maximum of 4 compiler processes at

    any given time, which usually fits within the 16 GB RAM limit.

Solution

If you want to use the CMake CLI wrapper safely, you should explicitly pass the

CPU count to it, similar to what you did with make:

cmake --build . --parallel $(nproc)