hans@, are you a right owner for this? I assumed so because of issue 730945 :)

Yes, thanks.

We may also want r305177 for  issue 727633 .

Trying r305281 today: https://codereview.chromium.org/2941553002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a26e05c70e63815c7c18284e5e006b9d0ac75af

commit 3a26e05c70e63815c7c18284e5e006b9d0ac75af
Author: hans <hans@chromium.org>
Date: Wed Jun 14 00:05:05 2017

Roll clang 303910:305281.

BUG= 731130 

Review-Url: https://codereview.chromium.org/2941553002
Cr-Commit-Position: refs/heads/master@{#479214}

[modify] https://crrev.com/3a26e05c70e63815c7c18284e5e006b9d0ac75af/tools/clang/scripts/update.py

Correction to c#1, I meant  issue 714769 .

Unfortunately, there was a change to ASan that breaks clusterfuzz in r303941. The semantics of ASAN_OPTIONS=handle_signal=1 was changed (ASAN_OPTIONS=handle_signal=2 is the equivalent, but that isn't backwards compatible). 

vitalybuka@ said that he will make a compatibility fix. Should we revert the roll until that fix is in?

We only revert for things covered by https://build.chromium.org/p/chromium.fyi/console?category=clang%20tot , main waterfall, and default cq bots.

Is that failure visible on those bots?

> Is that failure visible on those bots?

No, but it's something that Clusterfuzz heavily depends on, and it may cause security bugs filed in crbug by clusterfuzz to be incorrectly closed as Fixed.

On the other hand, ClusterFuzz has filed new bugs that were the result of fixes in the roll, which would get incorrectly marked as Fixed if we revert.

vitalybuka@, do you have an ETA for the fix? maybe we can just roll forward instead?

Is there a bug for the clusterfuzz problem? Can we update our ClangToTLinuxAsan builder to match the configuration that needs to be tested?

We have some discussion about the problem in https://github.com/google/oss-fuzz/issues/675#issuecomment-308565132, and it applies to the chromium instance of ClusterFuzz too.

I'm not sure if this can be tested easily in ClangToTLinuxAsan. We need to make sure that ASan signal handlers are correctly kicking in specific cases. Perhaps this can be added as a test an LLVM test once the fix is landed?

Do you need the backwards compat on CF? Why doesn't setting to 2 work there?

If we fuzz on old branches, we could get the right value from some file in src (and if that doesn't exist, cf would default to 1). 

Compatibility fix is r305433 https://reviews.llvm.org/D34227 
For now you need to set ASAN_OPTIONS=allow_user_segv_handler=0 and it will work for pre-r303941 and post-r305433.
When support of pre-r303941 is not needed please switch to
ASAN_OPTIONS=handle_segv=2:handle_sigbus=2:handle_sigfpe=2

Thanks! Would it be possible to roll past that? Should we create a new bug for it?

> If we fuzz on old branches, we could get the right value from some file in src (and if that doesn't exist, cf would default to 1). 

That adds a lot of complexity for us, and we'd like to avoid it if possible.

Can you answer the questions in comment 15?

Yes, we do need backwards compat on CF. Setting to 2 breaks older builds on startup because the option expected a boolean and not a number.

We need to run older builds for regression range testing.

I believe I already answered the last question in comment 15 in #17.

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=733692 for the next roll; please cc yourselves there.

Marking this one fixed since the roll seems to be sticking.

ochang: Medium-term, I think it's probably wise to come up with some system where CF can use different settings on different branches. Maybe some of the CF config should live in src, so that that happens naturally. Want to file a bug for that?