Stellarium
Building Stellarium-Lite on Manjaro Linux spawns too many jobs, clogs CPU and memory, then OOM kills open user sessions
Expected Behaviour
Build process not to make the computer unresponsive while building Stellarium.
Actual Behaviour
Build process spawning as many jobs as cores and threads, clogging the CPU, causing memory overflow, which causes out-of-memory manager to kill the user sessions, eventually cancelling the build process.
No screenshot available, computer unresponsive shortly after the build process is started.
Steps to reproduce
On Manjaro Linux:
- yay -S stellarium-lite
then answer all questions with the default (press enter until the build process starts).
System
- Stellarium version: stellarium-lite 25.1-2
- Operating system:
- Manjaro Linux (rolling release, no version available)
- Linux kernel 6.12.21-4-MANJARO
- Desktop environment: Xfce
- cmake version: 4.0.0
- Ninja version: 1.12.1
- Graphics Card: AMD Radeon graphics (unrelated with the bug)
- Screen type: irrelevant
Logfile
No log file available, not enough resources available to capture anything that would exhibit the issue since CPU usage becomes too high to take any action.
Attempted steps to try fix the issue:
- Manually edit PKGBUILD to add the following Cmake arguments:
-DCMAKE_AUTOGEN_PARALLEL=2 \
-DAUTOGEN_PARALLEL=2 \
Still, all cores and threads are running 100%, eventually making the computer unresponsive until OOM kills user sessions. Setting the number of parallel jobs to 2 was an attempt to have a visual feedback on CPU usage as 2 threads/cores busy never results in a 100% load. This edit doesn't change anything to the build process, which spawns the maximum possible number of jobs anyway, ultimately making the system unresponsive until OOM takes unrecoverable actions (user sessions and compiling jobs killed).
- The problem was reported on Manjaro forums but was closed without further actions.
What is stellarium-lite? Not our package, maybe report elsewhere?
Generally: just make -j<CORES-2> or so?
If this is a build based on Qt5.15, note that Qt's translation tools of 5.15.[01] are buggy, 5.15.2 are working again.
How much RAM do you have? I have 8G on my laptop (which is tiny by today's measure), and I have to limit number of threads to 4 using -j4 argument to cmake --build command. This is completely expected and shouldn't be considered a bug in Stellarium.
What is stellarium-lite? Not our package, maybe report elsewhere?
Here are the two URLs mentioned in the package file:
- https://github.com/Stellarium/stellarium/releases/download/v25.1/stellarium-25.1.tar.gz
- https://github.com/Stellarium/stellarium/commit/bbcd60ae52b6f1395ef2390a2d2ba9d0f98db548.diff
Generally: just
make -j<CORES-2>or so?
Fact that cannot be run. Only the distribution's package manager and build toolchain can execute the build process. Here's the executed command line, as per the PKGBUILD file from the fetched package (on Arch User Repository):
build() {
PATH="/usr/bin/core_perl/:$PATH"
cmake \
-S ${_pkgname}-${pkgver} \
-B build \
-G Ninja \
-DCMAKE_POLICY_VERSION_MINIMUM=3.5 \
-DCMAKE_BUILD_TYPE=None \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_C_COMPILER=gcc \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_C_EXTENSIONS=Yes \
-DCMAKE_CXX_COMPILER=g++ \
-DCMAKE_C_STANDARD=17 \
-DCMAKE_CXX_EXTENSIONS=Yes \
-DENABLE_QT6=1 \
-DENABLE_SHOWMYSKY=ON \
-DENABLE_TESTING=0 \
-DENABLE_XLSX=0 \
-DENABLE_GPS=0 \
-DUSE_PLUGIN_TELESCOPECONTROL=0 \
-Wno-dev
cmake --build build --target all
}
(The above is the contents of the PKGBUILD file; I removed the two lines I added, which don't work anyway.)
I assumed that command line was suggested by the developers of Stellarium. Is my deduction incorrect? Shall I instead direct this bug report to Arch Linux package maintainer instead?
If this is a build based on Qt5.15, note that Qt's translation tools of 5.15.[01] are buggy, 5.15.2 are working again.
Qt6 is mentioned in the above excerpt so I suppose it should be fine?
How much RAM do you have? I have 8G on my laptop (which is tiny by today's measure), and I have to limit number of threads to 4 using
-j4argument tocmake --buildcommand. This is completely expected and shouldn't be considered a bug in Stellarium.
I have 16GB RAM but also 16 threads 2 threads per core), which is why (I suspect) the OOM kicks in and kills sessions as well as compile jobs¹: that number of compile jobs appears uncontrollable, at least the means I know of. Fact of the matter on my laptop I configured the build process (but it mostly uses make, not cmake) is as follows:
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j2"
#-- CMake parallel control (doesn't work)
# Doesn't work:
NINJAFLAGS="-j2"
# Doesn't work:
CMAKE_AUTOGEN_PARALLEL=2
# Doesn't work:
PARALLEL_LEVEL=2
# Doesn't work:
CMAKE_BUILD_PARALLEL_LEVEL=2
However I have to confess I know little to nothing about cmake and even less about ninja...
FTR, here's the header of the PKGBUILD file, as downloaded by Manjaro's AUR package manager (aka yay):
_pkgname=stellarium
pkgname=${_pkgname}-lite
pkgver=25.1
pkgrel=2
pkgdesc="Stellarium without GPS and Telescope Control support (no gpsd and libindi dependencies)"
arch=(x86_64)
url="https://${_pkgname}.org"
license=(GPL-2.0-or-later)
depends=(nlopt libpng libglvnd freetype2 openssl 'calcmysky>=0.3'
qt6-charts qt6-multimedia qt6-webengine )
makedepends=(cmake ninja mesa qt6-tools)
optdepends=('man-db: manual pages for stellarium')
conflicts=(${_pkgname})
source=(https://github.com/Stellarium/${_pkgname}/releases/download/v${pkgver}/${_pkgname}-${pkgver}.tar.gz{,.asc}
https://github.com/Stellarium/stellarium/commit/bbcd60ae52b6f1395ef2390a2d2ba9d0f98db548.diff)
validpgpkeys=('79151C2E6351E7278DA1A730BF38D4D02A328DFF') # Alexander Wolf <[email protected]>
sha256sums=('2ecbc90f0bc7f1355e4d6497db2adc9119000d88eb18a3b4257ce249c4bea2f0'
'SKIP'
'1797a4a633a39d989ea7e688dd600a19655ba1d798b74972f9f85e6452152cfd')
¹ As compiled files seem pretty large, each compiler instance may eat more than 1GB RAM so I'm not surprised the out-of-memory manager kicks in.