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

commit 84483870696a49006efa37803488fe7a12ae3aa6
Author: Xida Chen <xidachen@chromium.org>
Date: Sat Jun 24 01:09:26 2017

Mark nested-cloning-large-multiple.html timeout on MSAN

TBR=pwnall@chromium.org
NOTRY=true

Bug: 736554
Change-Id: I732fdebda25e7c7c2d0b9d1d3c36b067817af476
Reviewed-on: https://chromium-review.googlesource.com/547275
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#482105}
[modify] https://crrev.com/84483870696a49006efa37803488fe7a12ae3aa6/third_party/WebKit/LayoutTests/MSANExpectations

Thank you very much for not reverting the CL! It fixes an important data loss issue.

There isn't much I can do about the timeout. Is there a way to get MSAN folks to revisit their timeout multiplier?

The CL that you point to took an old test case and sharded it, and this test case is almost as small as it can get. I can cut down its time by ~50% via one more sharding CL, but this is a fairly thin margin for a test timeout -- an IndexedDB throttling change could break the test again.

FWIW, the test runs in 9.6s in a debug build on my machine. The timeout for slow tests is 90s, so it seems to be well within the budget.

Maybe do a MSAN build on your local desktop and see what happens?
https://www.chromium.org/developers/testing/memorysanitizer

For what it's worth, external/wpt/IndexedDB/interleaved-cursors.html also seems to timeout more often than not on MSAN builds.

And some of the other nested-cloning-* test also seem to timeout a lot.

I'll bump the priority up a bit. Hopefully pwnall@ can take a look soon.