How did you end up with that perfetto.so? Looks like you are mixing a static and component build.
I am not familiar with cros workflow, can you figure out where the libperfetto.so comes from. 
(we run with asan on our waterfall on perfetto-ci.appspot.com and it's all green now. But this seems related to chrome bundling)

PS ccing all 6 owners seems a bit excessive. This doesn't look an emergency (seems related with your local tests). I would have cced 1-2 and/or pinged on im. 

> How did you end up with that perfetto.so?

All I did was set the gn args I provided in the original post and run the `ninja -C out/asan -j 100 chromeos_unittests` command to build. I didn't do any special setup. Is there anything I should be doing differently here?

> PS ccing all 6 owners seems a bit excessive.

Sorry about that - I removed the others.

I see where the ODR comes form, it's a side effect of the component build (is asan+component build a supported workflow?).
componnt-build is a side-effect of is_debug=true, I suspect that if you set is_component_build=false the ODR goes away.

Here's the ODR:
1) services/tracing/public/cpp/BUILD.gn  depends on //third_party/perfetto/protos/perfetto/trace:zero which in turn pulls //third_party/perfetto/protozero (as a source_set)

2) Some other chrome targets (e.g. services/tracing/public/cpp/BUILD.gn and services/tracing/BUILD.gn) depend on libperfetto that in turn pulls //third_party/perfetto/protozero (as a source_set)

1 and 2 are different linker units in a component build mode, so they hit the ODR by both exporting stuff defined in protozero's translation units.

+oysteine to figure out a solution for this (I think either we make protozero a component or we make things depend only on libperfetto and make the protos exports public).

But before this, I first need to figure out if asan+component is something that we should support (is it tested by any waterfall?)

primiano@: You're correct - adding "is_component_build = false" to my args made the problem go away. Downgrading to P2 since there's a workaround.

Putting up CL to fix this in Chrome once https://android-review.googlesource.com/c/platform/external/perfetto/+/711693 lands.

(Opted for the solution of dropping direct external dependencies on protozero targets within Perfetto, rather than making sub-components within Perfetto).

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

commit 04f2f5594f30c2a4c82a894aaedcbeb199623858
Author: Oystein Eftevaag <oysteine@google.com>
Date: Fri Jul 13 19:43:46 2018

Perfetto: Remove direct deps on generated protozero files

This is needed to avoid ODR violations due to both the generated protozero
sourcesets as well as libperfetto having dependencies on
third_party/perfetto/src/protozero (the protozero base library) which
causes ODR violations in component builds.

Requires https://android-review.googlesource.com/c/platform/external/perfetto/+/711693 to land.

R=hjd@chromium.org
BUG= 853872 

Change-Id: I805092df1a3e62662f478a7bac015686322d00db
Reviewed-on: https://chromium-review.googlesource.com/1120694
Reviewed-by: Hector Dearman <hjd@chromium.org>
Commit-Queue: oysteine <oysteine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575024}
[modify] https://crrev.com/04f2f5594f30c2a4c82a894aaedcbeb199623858/services/tracing/BUILD.gn
[modify] https://crrev.com/04f2f5594f30c2a4c82a894aaedcbeb199623858/services/tracing/public/cpp/BUILD.gn