Stop running components_unittests on linux_tsan

Stop running components_unittests on linux_tsan

Dmitry said TSAN v1 is deprecated and excluding tests is fine:

http://codereview.chromium.org/196793023/

In the above change, we will add a test for a new seccomp-bpf
filter into components_unittests and Seccomp-BPF is not
compatible with TSAN.

As far as I checked, these two builders are the only ones who
run components_unittests on TSAN v1.

BUG=243968, 359285
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=264360

[hamaji, 2014-04-16 17:15:55]

PTAL

I'm not sure who is the best reviewer for this buildbot change. If I should find
another person, please let me know.

[jln (very slow on Chromium), 2014-04-16 17:39:12]

lgtm (but I'm also not a great person for this).

[hamaji, 2014-04-16 17:51:29]

+agable

[agable, 2014-04-16 19:40:26]

This change looks fine from a purely syntactic perspective.

There are some things that need to be checked before it can land:
* Does the commit queue care about this step on the trybot?
* Does this test run anywhere on the main waterfall, so that removing it from a
trybot would reduce our pre-main-waterfall coverage?
* How confident are you that these are the only bots running tsanv1? Can they be
converted to run tsanv2 instead?

[hamaji, 2014-04-16 20:41:42]

Thanks for the comment!

> This change looks fine from a purely syntactic perspective.
> There are some things that need to be checked before it can land:
> * Does the commit queue care about this step on the trybot?

No, I believe. I mean, when I land a CL by the commit queue, I don't see
linux_tsan in the list of "Trybot results" above the commit queue checkbox.

> * Does this test run anywhere on the main waterfall, so that removing it from
a trybot would reduce our pre-main-waterfall coverage?

I believe memory.fyi is the only instance where we run the same test.

http://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20Tests%20%28t...

This change removes this testcase from memory.fyi as well.

> * How confident are you that these are the only bots running tsanv1? Can they
be converted to run tsanv2 instead?

To be honest, I'm only 80% sure. What I did was:

I grepped masters/ directory by tsan and found the following directories.

master.chromium.fyi: The TSAN bots in
http://build.chromium.org/p/chromium.fyi/console are v2
master.chromium.lkgr: I think they only compile, and do not run test:
http://build.chromium.org/p/chromium.lkgr/console
master.chromium.memory.fyi: I'm removing components_unittests from this bot.
master.client.libyuv: "grep components" finds nothing
master.client.webrtc: "grep components" finds nothing
master.client.webrtc.fyi: "grep components" finds nothing
master.tryserver.chromium: This CL is changing this.
master.tryserver.libyuv: "grep components" finds nothing
master.tryserver.webrtc: "grep components" finds nothing

I did the same for build_internal and found nothing.

As for the second question, I think TSAN v2 is running the same test. You can
see components_unitttests in

http://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20Tests%20%28T...


Is there anything else I can do to make sure this is OK?

[hamaji, 2014-04-16 23:39:02]

BTW, will we need to restart buildbot masters to make the new configs work? If
so, we cannot land http://codereview.chromium.org/196793023/ until the restart
happens, which isn't ideal...

Julien, if this is the case, does it make sense to add "if
(IsRunningOnValgrind()) return;" to the all test cases for the meantime? Maybe I
#define a macro for this, and add a TODO.

[jln (very slow on Chromium), 2014-04-16 23:43:48]

On 2014/04/16 23:39:02, hamaji wrote:
> BTW, will we need to restart buildbot masters to make the new configs work? If
> so, we cannot land http://codereview.chromium.org/196793023/ until the restart
> happens, which isn't ideal...
> 
> Julien, if this is the case, does it make sense to add "if
> (IsRunningOnValgrind()) return;" to the all test cases for the meantime? Maybe
I
> #define a macro for this, and add a TODO.

Since the affected bot is in memory.FYI, I think it's ok to break to it until
the WF restarts. You should ping chrome-infra@ once this lands to ask for a
restart.

I'm not opposed to IsRunningOnValgrind() return, but it looks like a lot of
effort in comparison to landing this.

[agable, 2014-04-17 00:05:42]

On 2014/04/16 23:43:48, jln wrote:
> On 2014/04/16 23:39:02, hamaji wrote:
> > BTW, will we need to restart buildbot masters to make the new configs work?
If
> > so, we cannot land http://codereview.chromium.org/196793023/ until the
restart
> > happens, which isn't ideal...
> > 
> > Julien, if this is the case, does it make sense to add "if
> > (IsRunningOnValgrind()) return;" to the all test cases for the meantime?
Maybe
> I
> > #define a macro for this, and add a TODO.
> 
> Since the affected bot is in memory.FYI, I think it's ok to break to it until
> the WF restarts. You should ping chrome-infra@ once this lands to ask for a
> restart.
> 
> I'm not opposed to IsRunningOnValgrind() return, but it looks like a lot of
> effort in comparison to landing this.

Great, thanks for the due diligence! LGTM.

Yes, this change will require master restarts of both chromium.memory.fyi and
tryserver.chromium. Please request both of those restarts via an email to
chrome-troopers@. I don't know what the tolerance for breaking the linux_tsan
trybots and the memory.fyi waterfall is, but I'd guess low. Please land and wait
for restarts before landing the other change if at all possible.

[hamaji, 2014-04-17 00:06:48]

The CQ bit was checked by hamaji@chromium.org

[commit-bot: I haz the power, 2014-04-17 00:07:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hamaji@chromium.org/238353010/1

[commit-bot: I haz the power, 2014-04-17 00:07:51]

Change committed as 264360