I think the most reasonable course of action here is to add some uninit-read-triggering logic to IPC::ChannelProxy::Send which only compiles if defined(MEMORY_SANITIZER).

Note that while msan bots don't currently catch these bugs, it's only because of  issue 619972 . That doesn't block this since we can just trigger the error using some other mechanism like conditional branching.

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

commit bf1598991bbbf0a9b34764a37a9c1b97ea50ca4f
Author: rockot <rockot@chromium.org>
Date: Fri Jun 24 23:33:42 2016

Remove uninit read suppression for Mojo EDK writes

This is a common codepath through which all IPC data is
transmitted. Suppressing this supresses all potential
uninitialized read bugs in any code which prepares IPC
messages for transit (e.g. any IPC::ParamTraits
implementation.)

This suppression was recently relanded as a result of an
uninitialized read in some IPC message contents. It's possible
that the actual bug has been fixed, but it's unclear.

Since I'm unable to repro locally I'm removing the suppression
to see if the memory bots go red again.

Memory sheriffs *please* ping rockot@ before relanding this
suppression.

BUG= 398547 , 623235 
TBR=amistry@chromium.org

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

[modify] https://crrev.com/bf1598991bbbf0a9b34764a37a9c1b97ea50ca4f/tools/valgrind/drmemory/suppressions_full.txt

Actually, looks like base::Pickle already uses MSAN_CHECK_MEM_IS_INITIALIZED so this bug is invalid. If uninit bytes show up again they must be coming from somewhere else.