MAybe merge with  bug 599769 ?

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

commit 41e14d24ad52a354e6b493a17935b2797b743f5a
Author: thestig <thestig@chromium.org>
Date: Thu Apr 14 01:29:26 2016

DrMemory: Exclude a failing remoting test case.

BUG= 603357 
TBR=jyasskin@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/1882933003

Cr-Commit-Position: refs/heads/master@{#387195}

[modify] https://crrev.com/41e14d24ad52a354e6b493a17935b2797b743f5a/tools/valgrind/gtest_exclude/remoting_unittests.gtest-drmemory_win32.txt

Joe, can you take a look?

 Issue 599769  has been merged into this issue.

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

commit 35b79b13f17c4429107bef826c8b773f0c9b2336
Author: joedow <joedow@chromium.org>
Date: Tue Apr 19 21:11:35 2016

Fixing a Dr. Memory hang in the remoting_unittests

There were two problems that needed to be addressed.  One was a failure that
occurred if a stream writer wrote the message type and payload in separate
write actions (timing problem) the second was a test bug in the
MultipleMessages test which did not check for success/failure for each loop
iteration.

The first problem was a timing issue where the reader might fail if the message
payload was written separately from the type and was not written quickly.  This
was not repro'd on normal builds but we see it on the Dr. Memory bot since
operations are slowed down as a result of the build flags used for the tool. I
fixed this problem by reading in the type and payload separately.

The second problem was in the unit test itself.  If an error occurred in the
Multiple messages test, the loop would write to the end of the pipe and wait
(forever) for an answer.  We now verify the message was written after every
iteration.

BUG= 603357 

Review URL: https://codereview.chromium.org/1900733002

Cr-Commit-Position: refs/heads/master@{#388307}

[modify] https://crrev.com/35b79b13f17c4429107bef826c8b773f0c9b2336/remoting/host/security_key/remote_security_key_message_reader_impl.cc
[modify] https://crrev.com/35b79b13f17c4429107bef826c8b773f0c9b2336/remoting/host/security_key/remote_security_key_message_reader_impl.h
[modify] https://crrev.com/35b79b13f17c4429107bef826c8b773f0c9b2336/remoting/host/security_key/remote_security_key_message_reader_impl_unittest.cc

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

commit 6be0c79c939096ab34fa4b3688c225caa798f054
Author: joedow <joedow@chromium.org>
Date: Thu Apr 21 01:24:30 2016

Removing Dr. Memory exclusion for the SecurityKeyReadyImpl.MultipleMessage test

I've fixed the underlying cause of the issue, verified it locally, and
submitted it yesterday: https://codereview.chromium.org/1900733002/

This change removes the exceptions from the text file so they can start
running on the Dr. Memory bot.

BUG= 603357 

Review URL: https://codereview.chromium.org/1910453004

Cr-Commit-Position: refs/heads/master@{#388657}

[modify] https://crrev.com/6be0c79c939096ab34fa4b3688c225caa798f054/tools/valgrind/gtest_exclude/remoting_unittests.gtest-drmemory_win32.txt

Verified the fix and revert of the exception was successful.  The MultipleMessages test is now running on Dr. Memory bot.