Comment # 1 on bug 1181479 from Ruediger Oertel

the last lines in that log are:
[10986s] [4035/4215] : && /usr/bin/cmake -E rm -f
lib64/libclangStaticAnalyzerFrontend.a &&
/home/abuild/rpmbuild/BUILD/llvm-11.0.1.src/stage1/bin/llvm-ar Dqc
lib64/libclangStaticAnalyzerFrontend.a 
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/AnalysisConsumer.cpp.o
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/AnalyzerHelpFlags.cpp.o
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/CheckerRegistry.cpp.o
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/CreateCheckerManager.cpp.o
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/FrontendActions.cpp.o
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/ModelConsumer.cpp.o
tools/clang/lib/StaticAnalyzer/Frontend/CMakeFiles/obj.clangStaticAnalyzerFrontend.dir/ModelInjector.cpp.o
&& /home/abuild/rpmbuild/BUILD/llvm-11.0.1.src/stage1/bin/llvm-ranlib -D
lib64/libclangStaticAnalyzerFrontend.a && :
[40994s] qemu-system-s390x: terminating on signal 15 from pid 125036 (<unknown
process>)


Job seems to be stuck here, killed. (after 30000 seconds of inactivity)
[41007s] ### VM INTERACTION END ###
[41008s] No buildstatus set, either the base system is broken
(kernel/initrd/udev/glibc/bash/perl)
[41008s] or the build host has a kernel or hardware problem...


so llvm is stuck, possibly because of memory pressure for 30000 seconds and
after that timeout the process gets killed (and subsequently fails with a
dubious error message as the build script can't find out what exactly
happened).

this is s390zp2a with worker VMs like
OBS_INSTANCE_MEMORY=$(( 12 * 1024 ))
OBS_WORKER_ROOT_SIZE=60000
OBS_WORKER_SWAP_SIZE=2000
OBS_WORKER_JOBS=6

so a VM with 12G memory gets stuck with 6 jobs. might be a compiler bug or the
processes really get large enough to stall the machine due to memory pressure.
these are already the largest worker instances we run, so you might try with
manually setting a different (lower) number of jobs in the specfile or similar.