On Wed, Jul 21, 2021 at 03:08:02PM +0200, Peter Krempa wrote: > On Wed, Jul 21, 2021 at 14:46:43 +0200, Tim Wiederhake wrote: > > The undefined behaviour sanitizer (UBSAN) defaults to merely printing an > > error message if it detects undefined behaviour. These error messages often > > end up in captured output and do not fail the tests, effectively hiding > > the warning. Make the test cases fail to make the issues visible. > > > > Signed-off-by: Tim Wiederhake <twiederh@xxxxxxxxxx> > > --- > > .gitlab-ci.yml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > > index 3cb6ff5e6b..4757139fa9 100644 > > --- a/.gitlab-ci.yml > > +++ b/.gitlab-ci.yml > > @@ -89,6 +89,8 @@ stages: > > - meson build --werror -Ddocs=disabled -Db_lundef=false -Db_sanitize="$SANITIZER" > > - ninja -C build; > > - ninja -C build test; > > + variables: > > + UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1 > > Is this being propagated as an env variable? In many cases in the > gitlab-ci there are entries doing 'export ENV=VAL' for some reason. Some of the exported variables rely on state provided by the shell ($pwd) or by the running container image ($CCACHE_WRAPPERSDIR), so they canot be declared in the "variables:" block. > If this really results in env variables then: Yes, it does. 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 :|
