Christian Brabandt <[email protected]> wrote: > Hi Dominique! > > On Mi, 25 Jan 2017, Dominique Pellé wrote: > >> Christian Brabandt wrote: >> >> > On Di, 24 Jan 2017, Christian Brabandt wrote: >> > >> >> On Di, 24 Jan 2017, Dominique Pellé wrote: >> >> > How about an address sanitizer build in Travis to catch >> >> > this kind of bugs earlier in CI? >> > >> > Here is a patch. >> > >> > Sample logfiles here: >> > https://travis-ci.org/chrisbra/vim/builds/194982196 >> > This was with patch 8.0.225 which did abort on the mentioned test: >> > https://s3.amazonaws.com/archive.travis-ci.org/jobs/194982204/log.txt >> > >> > Best, >> > Christian >> >> >> Nice. Thank you! >> >> Some remarks: >> >> 1) regarding asan, we could use -O1 instead of -O0 to >> speed up the Jenkins job. This is the advice from the >> asan documentation: >> >> === BEGIN QUOTE https://github.com/google/sanitizers/wiki/AddressSanitizer >> >> In order to use AddressSanitizer you will need to >> compile and link your program using clang with >> the -fsanitize=address switch. To get a reasonable >> performance add -O1 or higher. To get nicer stack >> traces in error messages add -fno-omit-frame-pointer. >> === END QUOTE >> >> 2) I see that patch also adds a ubsan build. >> Unlike asan which crashes in case of error, ubsan does >> not crash and only prints a message on the terminal. >> So I suppose that CI build will be green in case of >> ubsan error. In fact, running vim tests normally gives >> at least one ubsan error when dividing by 0.0 in >> eval.c:4092: >> >> 4090 /* We rely on the floating point library to handle divide >> 4091 * by zero to result in "inf" and not a crash. */ >> 4092 f1 = f1 / f2; >> >> If you search for "runtime error:", you can see those >> ubsan errors reported in the log, despite the build >> being green: >> >> https://s3.amazonaws.com/archive.travis-ci.org/jobs/194982205/log.txt >> >> 3) We can also make ubsan report the stack of the error if we do >> export UBSAN_OTIONS=print_stacktrace=1. See: >> >> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#stack-traces-and-report-symbolization >> >> But I'm not sure that this option is available in old versions >> of clang. I see that Travis uses clang-3.4 which is quite old. > > Okay, so how about that: > > diff --git a/.travis.yml b/.travis.yml > index 543b033f6..d0da120b2 100644 > --- a/.travis.yml > +++ b/.travis.yml > @@ -18,13 +18,16 @@ env: > # Mac OSX build > - BUILD=yes TEST=test COVERAGE=no FEATURES=huge SHADOWOPT= SRCDIR=./src > CHECK_AUTOCONF=no > "CONFOPT='--enable-perlinterp --enable-pythoninterp --enable-rubyinterp > --enable-luainterp'" > + # ASAN build > + - BUILD=yes TEST=test SANITIZER_CFLAGS="-g -O1 -fsanitize=address > -fno-omit-frame-pointer" FEATURES=huge SRCDIR=./src > + "CONFOPT='--enable-perlinterp --enable-pythoninterp --enable-rubyinterp > --enable-luainterp'" > > sudo: false > > git: > depth: 1 > > -# instead of a 6*2*2 matrix (2*os + 2*compiler + 6*env), > +# instead of a 8*2*2 matrix (2*os + 2*compiler + 8*env), > # exclude some builds on mac os x and linux > # linux: 2*compiler + 5*env + mac: 2*compiler + 2*env > matrix: > @@ -38,6 +41,9 @@ matrix: > - os: osx > env: BUILD=yes TEST=scripttests COVERAGE=yes CFLAGS=--coverage > LDFLAGS=--coverage FEATURES=huge SHADOWOPT= SRCDIR=./src CHECK_AUTOCONF=no > "CONFOPT='--enable-perlinterp --enable-pythoninterp > --enable-python3interp --enable-rubyinterp --enable-luainterp'" > + - os: osx > + env: BUILD=yes TEST=test SANITIZER_CFLAGS="-g -O1 -fsanitize=address > -fno-omit-frame-pointer" FEATURES=huge SRCDIR=./src > + "CONFOPT='--enable-perlinterp --enable-pythoninterp > --enable-rubyinterp --enable-luainterp'" > - os: linux > compiler: clang > env: BUILD=no TEST=unittests COVERAGE=yes CFLAGS=--coverage > LDFLAGS=--coverage FEATURES=huge SHADOWOPT= SRCDIR=./src CHECK_AUTOCONF=yes > @@ -45,6 +51,10 @@ matrix: > compiler: clang > env: BUILD=yes TEST=test COVERAGE=no FEATURES=small CONFOPT= > SHADOWOPT= SRCDIR=./src CHECK_AUTOCONF=no > - os: linux > + compiler: gcc > + env: BUILD=yes TEST=test SANITIZER_CFLAGS="-g -O1 -fsanitize=address > -fno-omit-frame-pointer" FEATURES=huge SRCDIR=./src > + "CONFOPT='--enable-perlinterp --enable-pythoninterp > --enable-rubyinterp --enable-luainterp'" > + - os: linux > env: BUILD=yes TEST=test COVERAGE=no FEATURES=huge SHADOWOPT= > SRCDIR=./src CHECK_AUTOCONF=no > "CONFOPT='--enable-perlinterp --enable-pythoninterp > --enable-rubyinterp --enable-luainterp'"
Hi Christian It looks OK. But it's perhaps overkill to have a asan build for Linux and macOs, given than asan run takes longer than a normal build? I also noticed that on my machine, Vim built with asan is much faster when using clang than when using gcc. I'm not sure why, and whether it happens for other machines or compiler version. If it does, it's best to use clang for asan. There are quite some differences in the asan implementations for gcc and clang judging from this page: https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC Thanks! Dominique -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
