It' failing flakily now. Other failed builds:

https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1226
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1228
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1229
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1230
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1231


The tests fail with Timeout.

Sample logs:

Regressions: Unexpected timeouts (1)
  external/wpt/IndexedDB/large-nested-cloning.html [ Timeout ]  

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

commit f01f939a453471ba2924549c7f4c3d80eca3189a
Author: guidou <guidou@chromium.org>
Date: Mon May 29 08:58:58 2017

Update TestExpectations for timed-out test

external/wpt/IndexedDB/large-nested-cloning.html is timing out flakily on a Linux
MSAN bot.

BUG=727014
NOTRY=true
TBR=pwnall@chromium.org

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

[modify] https://crrev.com/f01f939a453471ba2924549c7f4c3d80eca3189a/third_party/WebKit/LayoutTests/TestExpectations

Updated TestExpectations to allow timeout on Linux.

pwnall@: you authored the test. Can you take a look or help find a better owner?

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

commit b1b454cce34a621d2a3a004d4b5a83e5d21f4724
Author: Quinten Yearsley <qyearsley@google.com>
Date: Wed Jun 07 00:33:44 2017

Remove flaky TestExpectations for tests which appear non-flaky recently.

This change was made by the update-test-expectations script.

Recent test results history:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_layout_tests&tests=virtual/mojo-loading/http/tests/inspector/search/sources-search-scope.html,external/wpt/IndexedDB/large-nested-cloning.html,virtual/threaded/fast/compositorworker/compositor-proxy-supports.html

BUG= 521853 ,727014, 728036 

Change-Id: I2de7202d6f3533da2e2477fc6fc204ad95d164cb
Reviewed-on: https://chromium-review.googlesource.com/526052
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Quinten Yearsley <qyearsley@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477486}
[modify] https://crrev.com/b1b454cce34a621d2a3a004d4b5a83e5d21f4724/third_party/WebKit/LayoutTests/TestExpectations

sheriff-o-matic showed this potential regression range:

https://chromium.googlesource.com/chromium/src/+log/711ff9d774dd4812e735be0bcd6b548851a75360%5E..188f19f9e26e879ac7aab7ac4bc54ba8cc57eb91?pretty=fuller

jam@'s 188f19f9e26e879ac7aab7ac4bc54ba8cc57eb91 and dmurph@'s d007b8b750851fe1b375c463009ea3b24e5c021d miggght be related.

i'm going to update expectations.

My cl isn't triggered, it's only for a code path that's off by default.

ah, ok

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

commit 33410c576598d429b7fcda68179e1e8bf932f841
Author: Dan Beam <dbeam@chromium.org>
Date: Wed Jun 07 21:09:26 2017

Update expectations to disable external/wpt/IndexedDB/large-nested-cloning.html again

Failing on WebKit Linux Trusty MSAN
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1275
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/1274

TBR=dmurph@chromium.org
BUG=727014

Change-Id: I9352dd582d101b811259e58347e0edcbf399b221
Reviewed-on: https://chromium-review.googlesource.com/527673
Reviewed-by: Dan Beam <dbeam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477757}
[modify] https://crrev.com/33410c576598d429b7fcda68179e1e8bf932f841/third_party/WebKit/LayoutTests/TestExpectations

dbeam@: IMHO, if the test passes on all the other bots, this indicates the problem is on the side of the xSAN bots, and their timeout multiplier should be increased.

In this case, I can break up the test a bit. That has non-zero cost -- more boilerplate, test file names / descriptions make less sense because this is an arbitrary split.

However, what's worse is... I'll probably land other tests that have the same problem, and we'll have to go through this dance again. Our IndexedDB implementation is going to get more complex as we aim to scale better, and we'll need more elaborate tests to cover it. The tests will go through the CQ just fine, and fail on xSAN bots.

Can we figure out a better long-term fix? Ideally, if a test doesn't time out on the CQ bots, it shouldn't time out on the xSAN bots either. This may mean that the xSAN timeout needs to be significantly more permissive than the timeout of the CQ bots, and we'd rely on the CQ bots to protect against spinloop tests that'd eat up too much CPU time on the xSAN bots.

Assigning this to you until we finish the conversation.

if there's an *SAN-specific expectations, why not just move to there?

We should make perf tests on some of these complex use cases to make sure
we don't regress and cause test timeouts

I'm no longer working on Chrome, and unlikely to fix any bug I'm currently assigned.

So this bug doesn't languish, I'm unassigning myself.