Hi Dominique!

On Mi, 25 Jan 2017, Dominique Pellé wrote:

> 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

It only adds the ASAN build for clang on linux. The other part of the 
patch is there to exclude those builds from the build matrix. 

Initially I tried with gcc but it failed for me, so I switched only 
clang on.

Best,
Christian
-- 
Glaube unbedingt an das Gute im Menschen, und rechne mit dem
Schlechten in ihm.
                -- Friedrich Dürrenmatt

-- 
-- 
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.

Raspunde prin e-mail lui