mkosi: Sanitizers

[DaanDeMeyer]

No description provided.

[github-actions]

Important

An -rc1 tag has been created and a release is being prepared, so please note that PRs introducing new features and APIs will be held back until the new version has been released.

[bluca]

Loaded 'libidn2.so.0' via dlopen()
Loaded 'libcryptsetup.so.12' via dlopen()
Loaded 'libpwquality.so.1' via dlopen()
Loaded 'libtss2-esys.so.0' via dlopen()
Loaded 'libtss2-rc.so.0' via dlopen()
Loaded 'libtss2-mu.so.0' via dlopen()
Loaded 'libfido2.so.1' via dlopen()
Loaded 'libbpf.so.1' via dlopen()
Loaded 'libdw.so.1' via dlopen()
Loaded 'libelf.so.1' via dlopen()
Loaded 'libpcre2-8.so.0' via dlopen()
Loaded 'libp11-kit.so.0' via dlopen()
Loaded 'libarchive.so.13' via dlopen()
Loaded 'liblz4.so.1' via dlopen()
Loaded 'libzstd.so.1' via dlopen()
Loaded 'liblzma.so.5' via dlopen()
Loaded 'libkmod.so.2' via dlopen()
Tracer caught signal 11: addr=0x3f000008 pc=0x7f8eb7841968 sp=0x7f8eb07d1d20
==49433==LeakSanitizer has encountered a fatal error.

[bluca]

Without sanitizer the integration test runs takes about 50 minutes, with sanitizers about 90 minutes - that's quite a bump. Also, I am very worried that by making things slower, we'll hide more race conditions (like the ones we found in the past few weeks). Hence, I'd prefer if we had one job that runs with sanitizers, and the rest without. We could maybe to a weekly run with all jobs.

[DaanDeMeyer]

Without sanitizer the integration test runs takes about 50 minutes, with sanitizers about 90 minutes - that's quite a bump. Also, I am very worried that by making things slower, we'll hide more race conditions (like the ones we found in the past few weeks). Hence, I'd prefer if we had one job that runs with sanitizers, and the rest without. We could maybe to a weekly run with all jobs.

Isn't it the opposite? I'm pretty sure that the reason we uncovered all those race conditions is because the tests in Github Actions run with drastically fewer resources than they do in CentOS CI.

[bluca]

Without sanitizer the integration test runs takes about 50 minutes, with sanitizers about 90 minutes - that's quite a bump. Also, I am very worried that by making things slower, we'll hide more race conditions (like the ones we found in the past few weeks). Hence, I'd prefer if we had one job that runs with sanitizers, and the rest without. We could maybe to a weekly run with all jobs.

Isn't it the opposite? I'm pretty sure that the reason we uncovered all those race conditions is because the tests in Github Actions run with drastically fewer resources than they do in CentOS CI.

I thought they were faster here? But anyway, same thing other way around: a mix of the two would be best, so that we have more variations in the base environment

[bluca]

Would it be possible to just skip this test case under sanitizers? I quite like having this as part of the unit test run, rather than the integration test run, as it's much faster feedback

[DaanDeMeyer]

A unit test really shouldn't be doing what this test is doing, I think this just fits much better as an integration test. I'd much rather have us focus on speeding up the integration tests rather than trying to fit stuff that should be an integration test in a unit test.

[bluca]

An integration test running in a VM will never be able to run in a handful of seconds though, and it also won't be able to run at package build time. Of course I'm not asking to make it work under sanitizers, that would be way too involved, and having the same test case also in the integration test is nice. But I'd really like to keep this, and just have it skipped if sanitizers are enabled, that should be simple enough?