Probably MSan is so slow that we do something with MSan enabled that we normally don't have time to do with it disabled.  I'll disable the test with the network service enabled.

It's a crash, which shouldn't happen even if MSan is slowing things down drastically.

So suppose we have a test that does Foo asynchronously...The critical path of the test normally completes so quickly, we don't reach the point where we do Foo.  MSan, however, slows the critical path down sufficiently that we reach the point where to do Foo, which always causes a crash.

MSan isn't causing the crash, it's causing us to give the code causing the crash long enough to run and crash.

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

commit 02732adb3eb8516631d86fa010ad7f235d73b008
Author: Matt Menke <mmenke@chromium.org>
Date: Wed Jun 20 21:31:54 2018

Disable SocketApiTest.SocketUDPExtension with the NetworkService enabled

It flakily reaches a point of execution where extensions try to
do a host resolution using the RequestContext, which isn't set up when
the network service is enabled.

TBR=jam@chromium.org

Bug:  854762 
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: I5883a5620b953ca40fd582d39b96ea29f4f988e9
Reviewed-on: https://chromium-review.googlesource.com/1108737
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569027}
[modify] https://crrev.com/02732adb3eb8516631d86fa010ad7f235d73b008/testing/buildbot/filters/mojo.fyi.network_browser_tests.filter

Why is the bug fixed? Is it impossible for this timing issue to manifest in production?

The network service is not used in production.  The test only failed in the test fixture when the network service was enabled.  Keeping an extra open bug for this particular issue when we have dozens of consumers to convert to a new API that doesn't exist yet also seems not a productive use of time.

To explain further:  HostResolver itself is deprecated, in favor of a Mojo API that's still being worked on.  Certain consumers who try to use it when the network service is enabled crash.  We need to update them to the new API once we have it.

We will, at some point, need to audit existing consumers, and possibly make the old API inaccessible.  This bug provides no benefit to that, and it actually provides an extra step - anyone converting an API found in the audit would need to find this bug, realize it's related to the code he's working on, and mark this bug as fixed, as opposed to just filing a new one for that particular consumer.

Makes sense. Thanks for the explanation and the quick fix!