[PATCH] D18167: [ELF/Driver] Avoid a reference to the ELFOptTable after it has gone out of scope

Kostya Serebryany via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 16 15:28:11 PDT 2016


Interesting.
Looking at
https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/buildbot_functions.sh
I see export ASAN_OPTIONS="check_initialization_order=true:
*detect_stack_use_after_return=1*:detect_leaks=1"
So, it's already enabled on the bots.
But, I also see this:

  if [ "$CHECK_LLD" != "0" ]; then
    echo @@@BUILD_STEP check-lld ${sanitizer_name}@@@
    # TODO(smatveev): change this to STEP_FAILURE once green
    (cd ${build_dir} && ninja check-lld) || *echo @@@STEP_WARNINGS@@@*
  fi


So, check-lld is being run, but errors are not e-mailed to anyone.
Today there are errors from lsan, msan, and ubsan
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11154

Once you (or someone) cleans up these errors we may enable check-lld to
actually produce errors on buildbot.


--kcc


On Tue, Mar 15, 2016 at 5:00 PM, Filipe Cabecinhas <
filcab+llvm.phabricator at gmail.com> wrote:

> Ah, I didn't even need to check. Lit passing the ASAN_OPTIONS flag was
> what allowed us to find the bug easily. Without setting ASAN_OPTIONS
> you wouldn't find the bug with ASan.
>
> Thank you,
>
>   Filipe
>
> On Tue, Mar 15, 2016 at 4:59 PM, Filipe Cabecinhas
> <filcab+llvm.phabricator at gmail.com> wrote:
> > No. Lit actually passes them on to the environment:
> >
> > utils/lit/lit/TestingConfig.py:
> >         pass_vars = ['LIBRARY_PATH', 'LD_LIBRARY_PATH', 'SYSTEMROOT',
> 'TERM',
> >                      'LD_PRELOAD', 'ASAN_OPTIONS', 'UBSAN_OPTIONS',
> >                      'LSAN_OPTIONS', 'ADB', 'ANDROID_SERIAL']
> >         for var in pass_vars:
> >             val = os.environ.get(var, '')
> >             # Check for empty string as some variables such as
> > LD_PRELOAD cannot be empty
> >             # ('') for OS's such as OpenBSD.
> >             if val:
> >                 environment[var] = val
> >
> > I think we're safe.
> >
> > Thank you,
> >
> >   Filipe
> >
> > On Tue, Mar 15, 2016 at 4:24 PM, Kostya Serebryany <kcc at google.com>
> wrote:
> >> Cool!
> >> please make sure that the LLVM test harness does not unset ASAN_OPTIONS
> >>
> >> On Tue, Mar 15, 2016 at 4:17 PM, Filipe Cabecinhas
> >> <filcab+llvm.phabricator at gmail.com> wrote:
> >>>
> >>> Hi Kostya,
> >>>
> >>> ASan-ized lld gets past check-lld without problems, so we might not
> >>> need any cleanup :-)
> >>>
> >>> Thank you,
> >>>
> >>>   Filipe
> >>>
> >>> On Tue, Mar 15, 2016 at 3:52 PM, Kostya Serebryany <kcc at google.com>
> wrote:
> >>> >
> >>> >
> >>> > On Mon, Mar 14, 2016 at 7:29 PM, Filipe Cabecinhas
> >>> > <filcab+llvm.phabricator at gmail.com> wrote:
> >>> >>
> >>> >> It looks like it should, but I can't try it out now.
> >>> >> I can try it tonight or tomorrow morning at most. If you want, you
> can
> >>> >> compile llvm+lld with ASan and turn on the Asan option (double-check
> >>> >> that
> >>> >> you catch the bug first ;-) ).
> >>> >>
> >>> >> CCing Kostya:
> >>> >> Should we add ASAN_OPTIONS=detect_stack_use_after_free=true to the
> >>> >> sanitizer bot?
> >>> >
> >>> >
> >>> > That would be lovely!
> >>> > Any volunteers for the cleanup?
> >>> >
> >>> >>
> >>> >> It would have caught this bug a long time ago.
> >>> >> We might also need to do some cleanup before we can do it.
> >>> >>
> >>> >> Thank you,
> >>> >>
> >>> >>   Filipe
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Monday, 14 March 2016, Rui Ueyama <ruiu at google.com> wrote:
> >>> >>>
> >>> >>> ruiu added a comment.
> >>> >>>
> >>> >>> Does http://reviews.llvm.org/D18169 solves PR26908?
> >>> >>>
> >>> >>>
> >>> >>> http://reviews.llvm.org/D18167
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160316/9749228b/attachment.html>


More information about the llvm-commits mailing list