Martchus

This should be fixed by https://github.com/Martchus/cpp-utilities/commit/e79fcf793e4ff3ab90ec870496349725cd9b76dd but I haven't had the time to test it yet.

My Android builds (which also use this configuration) work so I guess this can be closed.

> I'm having to kill tons of qemu processes and restart worker processes, or just restart the affected systems periodically, or else I lose all the workers. Normally the openQA...

I also couldn't find a way to read the signal masks of a coredump. The best I can currently think of is to add a few more sanity checks in...

Maybe you can add the check @Vogtinator mentioned somewhere in your production deployments (where you can reproduce the error) like I did it for our tests in https://github.com/os-autoinst/os-autoinst/pull/2551/files#diff-9e94ac1686eef02708b9f17f65398b6799f035b167e417966aca064f40bfa4bd.

I'll have a look into your suspicion that this spawns one thread too less and maybe adjust my pending PR to extend tests and change the implementation if necessary. If...

I had a quick look at the code. It uses the following formula to determine the number of threads to spawn: `std::max(1, std::min(cv::getNumThreads(), cv::getNumberOfCPUs() - 1));`. So we always spawn...

I pushed another change to https://github.com/os-autoinst/os-autoinst/pull/2551 which should fix the `-1` problem.

By the way, we actually have also a [ticket about that](https://progress.opensuse.org/issues/53999) and the problem is probably still reproducible (as we have lots of crashes according to coredumpctl on production workers;...

Right, there's actually an explaining comment. Maybe the mentioned TBB function has changed. I'll look into it. And yes, I've also noticed that we actually set the thread count explicitly....