ASan: re-enable strict memcmp() checks.

ASan: re-enable strict memcmp() checks.

Also, introduce ASan suppressions and use them to suppress a memcmp()
report in system-installed libsqlite.

BUG=178677
TBR=glider@chromium.org

Committed: https://crrev.com/01151d346358a1911639a97fd061393bc0b54e43
Cr-Commit-Position: refs/heads/master@{#324448}

[Alexander Potapenko, 2015-04-09 10:22:21]

https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/asan_s...
File build/sanitizers/asan_suppressions.cc (right):

https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/asan_s...
build/sanitizers/asan_suppressions.cc:16: "interceptor_via_lib:libsqlite3.so\n"
Don't we want to make the suppressions OS-specific?

[earthdok, 2015-04-09 12:26:43]

On 2015/04/09 10:22:21, Alexander Potapenko wrote:
>
https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/asan_s...
> File build/sanitizers/asan_suppressions.cc (right):
> 
>
https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/asan_s...
> build/sanitizers/asan_suppressions.cc:16:
"interceptor_via_lib:libsqlite3.so\n"
> Don't we want to make the suppressions OS-specific?

Do we expect to see "libsqlite3.so" on Windows or Mac?

[Alexander Potapenko, 2015-04-09 12:47:25]

On 2015/04/09 12:26:43, earthdok wrote:
> On 2015/04/09 10:22:21, Alexander Potapenko wrote:
> >
>
https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/asan_s...
> > File build/sanitizers/asan_suppressions.cc (right):
> > 
> >
>
https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/asan_s...
> > build/sanitizers/asan_suppressions.cc:16:
> "interceptor_via_lib:libsqlite3.so\n"
> > Don't we want to make the suppressions OS-specific?
> 
> Do we expect to see "libsqlite3.so" on Windows or Mac?

Ok, let them stay together for now. Note that we may or may not want to have
different suppressions for Linux and CrOS.
LGTM

[earthdok, 2015-04-09 12:47:59]

The CQ bit was checked by earthdok@chromium.org

[commit-bot: I haz the power, 2015-04-09 12:48:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1070853002/20001

[commit-bot: I haz the power, 2015-04-09 15:50:12]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-04-09 15:51:09]

Patchset 2 (id:??) landed as
https://crrev.com/01151d346358a1911639a97fd061393bc0b54e43
Cr-Commit-Position: refs/heads/master@{#324448}

[jamesr, 2015-05-06 00:01:27]

jamesr@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2015-05-06 00:01:28]

https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/saniti...
File build/sanitizers/sanitizers.gyp (right):

https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/saniti...
build/sanitizers/sanitizers.gyp:46: 'asan_suppressions.cc',
shouldn't this file be added to the GN build as well?  specifically here:
https://chromium.googlesource.com/chromium/src/+/master/build/config/sanitize...

[earthdok, 2015-05-06 00:50:11]

On 2015/05/06 00:01:28, jamesr wrote:
>
https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/saniti...
> File build/sanitizers/sanitizers.gyp (right):
> 
>
https://codereview.chromium.org/1070853002/diff/20001/build/sanitizers/saniti...
> build/sanitizers/sanitizers.gyp:46: 'asan_suppressions.cc',
> shouldn't this file be added to the GN build as well?  specifically here:
>
https://chromium.googlesource.com/chromium/src/+/master/build/config/sanitize...

That GN config looks pretty confused. We should append
"-Wl,-u_sanitizer_options_link_helper" whenever we link in sanitizer options -
not just when is_asan is true. And why does the sanitizer_options_link_helper
config append the "-fsanitize=address" ldflag? The right place to append that
ldflag is wherever the same cflag is appended.

I didn't have the cycles to untangle the mess at the time, so I decided not to
touch GN. Anyway sanitizer support is mostly non-existent and will require a
focused effort.

[jamesr, 2015-05-06 00:51:42]

We're successfully using asan with GN which is why I'm asking.  It appears that
adding this file to the gn source_set makes asan work again.

[earthdok, 2015-05-06 16:54:23]

On 2015/05/06 00:51:42, jamesr wrote:
> We're successfully using asan with GN which is why I'm asking.  It appears
that
> adding this file to the gn source_set makes asan work again.

Sorry, I wasn't aware of that. Who is using it?

I can tell at least that leak detection support is not implemented (i.e. you can
configure with "is_asan=true is_lsan=true" but the latter flag doesn't do
anything).

[jamesr, 2015-05-06 17:29:55]

We're running asan (but not lsan, tsan, msan, ubsan, or any other *san) in Mojo.
 That uses the build configs from chromium although it lives in a different
repo.  Here's one bot:

http://build.chromium.org/p/client.mojo/builders/Mojo%20Linux%20ASan

it's been extremely useful at finding issues in the past and I believe it's
operating correctly now (I'll induce a failure locally to check).  Before we got
this set up we predictably had double-frees and other memory errors in lots of
our core code that was very difficult to diagnose without ASan's help.

We would love to run the rest of the sanitizer family as well on our binaries
but haven't had bandwidth to try to get them set up.

I know y'all are very busy and don't want to add any extra work, but if there
are any things you can provide that are easy (from your perspective) it'd
definitely help us out.

For this particular issue it looks like
https://chromium.googlesource.com/chromium/src/+/7080a81857e6a5be8eed11942ead...
fixed what we were seeing.