Re: [libvirt PATCH 6/6] ci: Enable address and undefined behavior sanitizers

On Mon, 2021-05-03 at 14:16 +0200, Pavel Hrdina wrote: > On Mon, May 03, 2021 at 12:01:46PM +0200, Tim Wiederhake wrote: > > meson supports the following sanitizers: "address" (e.g. out-of- > > bounds > > memory access, use-after-free, etc.), "thread" (data races), > > "undefined" > > (e.g. signed integer overflow), and "memory" (use of uninitialized > > memory). Note that not all sanitizers are supported by all > > compilers, > > and that more sanitizers exist. > > > > Not all sanitizers can be enabled at the same time, but "address" > > and > > "undefined" can. Both thread and memory sanitizers require an > > instrumented > > build of all dependencies, including libc. > > > > gcc and clang use different implementations of these sanitizers and > > have proven to find different issues. Create CI jobs for both. > > > > Signed-off-by: Tim Wiederhake <twiederh(a)redhat.com&gt; > > --- > > .gitlab-ci.yml | 35 +++++++++++++++++++++++++++++++++++ > > 1 file changed, 35 insertions(+) > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > > index 8b7df68f47..aa537e65fb 100644 > > --- a/.gitlab-ci.yml > > +++ b/.gitlab-ci.yml > > @@ -71,6 +71,26 @@ stages: > > rpmbuild --nodeps -ta build/meson-dist/libvirt-*.tar.xz; > > fi > > > > +.sanitizer_build_job: > > + stage: builds > > + image: $CI_REGISTRY_IMAGE/ci-ubuntu-2004:latest > > + needs: > > + - x64-ubuntu-2004-container > > Any specific reason for using Ubuntu 20.04? I would guess that we > want > to always use the latest compiler. It that's true I'm not sure which > distribution to pick: > > - Fedora $LATEST - we would need to change it every 6 months > > - Fedora rawhide - may be unstable and randomly fail if the > gcc/clang are broken > I chose Ubuntu 20.04 for no particular reason other than "the image already has the sanitizers installed and need no change". Fedora 33 and Rawhide both require additional packages installed (libasan and libubsan).

libvirt fails to build on Fedora Rawhide with gcc over what I believe to be a bug somewhere in the build chain. Output from one instance of the issue: ``` In file included from /usr/include/string.h:519, from ../source/src/internal.h:28, from ../source/src/rpc/virnettlscontext.h:23, from ../source/src/rpc/virnetclient.h:23, from ../source/src/rpc/virnetclient.c:27: In function ‘memcpy’, inlined from ‘virNetClientCallDispatchReply’ at ../source/src/rpc/virnetclient.c:1156:5, inlined from ‘virNetClientCallDispatch’ at ../source/src/rpc/virnetclient.c:1324:16, inlined from ‘virNetClientIOHandleInput’ at ../source/src/rpc/virnetclient.c:1497:23: /usr/include/bits/string_fortified.h:29:10: error: ‘__builtin_memcpy’ offset [148, 167] from the object at ‘client’ is out of the bounds of referenced subobject ‘prog’ with type ‘unsigned int’ at offset 144 [- Werror=array-bounds] 29 | return __builtin___memcpy_chk (__dest, __src, __len, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30 | __glibc_objsize0 (__dest)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../source/src/rpc/virnetmessage.h:23, from ../source/src/rpc/virnetclient.h:24, from ../source/src/rpc/virnetclient.c:27: ../source/src/rpc/virnetclient.c: In function ‘virNetClientIOHandleInput’: src/rpc/virnetprotocol.h:48:15: note: subobject ‘prog’ declared here 48 | u_int prog; | ^~~~ cc1: all warnings being treated as errors ``` Notice that source and destination of the memcpy referenced above are of type `virNetMessage`: ``` memcpy(&thecall->msg->header, &client->msg.header, sizeof(client- >msg.header)); ```

Using clang, libvirt builds just fine on Fedora Rawhide, but half of the tests fail with: ``` ==58582==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of SetAlternateSignalStack (error code: 22) (...) ==58582==AddressSanitizer CHECK failed: ../lib/sanitizer_common/sanitizer_common.cpp:54 "((0 && "unable to mmap")) != (0)" (0x0, 0x0) <empty stack> ``` On Fedora 33 (with libasan and libubsan installed manually), libvirt builds and tests fine with both clang and gcc, but find no additional issues in the code base. I cannot make a statement on the differences between the versions of (clang's) libasan and libubsan found in Ubuntu 20.04 and Fedora, but https://github.com/llvm/llvm-project/commits/main/compiler-rt/lib/asan and https://github.com/llvm/llvm-project/commits/main/compiler-rt/lib/ubsan/ suggest that not too many new features are added to sanitizers lately.