On Tue, May 04, 2021 at 12:50:09PM +0200, Tim Wiederhake wrote: > 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 <twied...@redhat.com> > > > --- > > > .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).
We should just be adding those to the container - libvirt-ci already knows about them from QEMU. > 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)); > ``` Rawhide is often hairy as it ships pre-release GCC builds alot of time, so we often end up having to file compiler bugs for regresions. This isn't entirely bad though, because it is better to find and fix problems in rawhide, than wait until they hit stable Fedora or RHEL. > 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
