I'm going to kick off a MSAN build and see if I can reproduce this locally.

I followed the instructions onhttps://www.chromium.org/developers/testing/memorysanitizer to build remoting_unittests and then simply running ./out/msan/remoting_unittests triggered the Webrtc/ConnectionTest.FirstCaptureFailed/0 failure for me.

Running the test case by itself fails as well: ./out/msan/remoting_unittests --gtest_filter=Webrtc/ConnectionTest.FirstCaptureFailed/0

And my normal build succeeds. Hope you can reproduce this as well. Let me know if you cannot and need help testing patches or what not.

This is now the last thing keeping the msan bot from going green.

https://build.chromium.org/p/chromium.memory.full/builders/Linux%20MSan%20Tests?numbuilds=200 -- sergeyu, can you look at this soon, or should we disable the test under msan for now?

Hi, I just started having issues with chrome remote desktop in the last week or so. reported the bug here: Issue 698053

Could it be related? thanks.

Probably not. I've updated that bug with some instructions.

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

commit fa09c695b8a976fdfcfca5b3c01e030e58288003
Author: thakis <thakis@chromium.org>
Date: Sat Mar 04 01:08:41 2017

Disable ConnectionTest.FirstCaptureFailed under msan.

The test fails under msan and it's the last thing keeping the msan bot
red.

BUG= 697178 

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

[modify] https://crrev.com/fa09c695b8a976fdfcfca5b3c01e030e58288003/remoting/protocol/connection_unittest.cc

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

commit 5e372bf6de94cb418ab952d9e33d2cfa0269e987
Author: sergeyu <sergeyu@chromium.org>
Date: Tue Mar 21 21:56:23 2017

Fix failed capture handling in WebrtcVideoStream

Previously, when a capture request fails, WebrtcVideoStream was
saving the corresponding event timestamp and then reusing it for
the following frame. That logic was implemented incorrectly - it
worked properly only when key_frame_request_ is set. This caused
the test to fail under MSAN as the key_frame_request_ is
set with a delay.

It's questionable if that logic is useful, so this CL removes it
together with the corresponding test. Also improved handling of
failed captures in WebrtcFrameSchedulerSimple.

BUG= 697178 

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

[modify] https://crrev.com/5e372bf6de94cb418ab952d9e33d2cfa0269e987/remoting/protocol/connection_unittest.cc
[modify] https://crrev.com/5e372bf6de94cb418ab952d9e33d2cfa0269e987/remoting/protocol/webrtc_frame_scheduler_simple.cc
[modify] https://crrev.com/5e372bf6de94cb418ab952d9e33d2cfa0269e987/remoting/protocol/webrtc_frame_scheduler_simple.h
[modify] https://crrev.com/5e372bf6de94cb418ab952d9e33d2cfa0269e987/remoting/protocol/webrtc_video_stream.cc
[modify] https://crrev.com/5e372bf6de94cb418ab952d9e33d2cfa0269e987/remoting/protocol/webrtc_video_stream.h