Suppress all reports from waterfall_drmem.sh.

tools/valgrind/drmemory/suppressions_full.txt

 # This file contains suppressions for the Dr.Memory tool, see
 # http://dev.chromium.org/developers/how-tos/using-drmemory
 #
 # This file should contain suppressions only for the reports happening
 # in the 'full' mode (drmemory_full).
 # For the reports that can happen in the light mode (a.k.a. drmemory_light),
 # please use suppressions.txt instead.
 
 ###############################################################
 # Known reports on the third party we have no control over.
@@ skipping 333 matching lines @@
 CRYPT??.dll!Crypt*
 
 UNINITIALIZED READ
 name=http://code.google.com/p/drmemory/issues/detail?id=412 g
 *!replace_memcmp
 ...
 *!testing::internal::CmpHelperEQ*
 ...
 *!SymmetricKeyTest_ImportGeneratedKey_Test::TestBody
 
+# We get these sometimes from AesEncrypt and AesExpandKey.  AesEncrypt doesn't
+# have frame pointers, and we have trouble unwinding from it.  Therefore, we use
+# this broad suppression, effectively disabling uninit checks in rsaenh.dll.
+UNINITIALIZED READ
+name=http://code.google.com/p/drmemory/issues/detail?id=712 h

[Timur Iskhodzhanov, 2012/02/09 10:50:18]

I prefer to sort the issues by their IDs.
Why "h" ?

[Reid Kleckner, 2012/02/09 15:17:37]

Should be issue 412, and h follows g.

+RSAENH.dll!*
+
 UNINITIALIZED READ
 name=http://code.google.com/p/drmemory/issues/detail?id=425 a
 CLBCatQ.DLL!DestroyStgDatabase
 CLBCatQ.DLL!PostError
 CLBCatQ.DLL!PostError
 
 LEAK
 name=http://code.google.com/p/drmemory/issues/detail?id=425 b
 RPCRT4.dll!I_RpcBCacheFree
 RPCRT4.dll!I_RpcBCacheFree
@@ skipping 67 matching lines @@
 ESENT.dll!*
 ntdll.dll!Ldr*Init*
 ntdll.dll!Ldr*
 ntdll.dll!*
 ntdll.dll!LdrLoadDll
 ...
 iphlpapi.dll!GetPerAdapterInfo
 ...
 iphlpapi.dll!GetAdaptersAddresses
 
+POSSIBLE LEAK
+name=http://code.google.com/p/drmemory/issues/detail?id=473 c
+RPCRT4.dll!*
+RPCRT4.dll!*
+...
+IPHLPAPI.DLL!GetAdaptersAddresses
+
 LEAK
 name=http://code.google.com/p/drmemory/issues/detail?id=475
 ...
 ADVAPI32.dll!CryptAcquireContextA
 ...
 CRYPT32.dll!CryptMsgOpenToDecode
 ...
 CRYPT32.dll!CryptQueryObject
 
+# Lots of leaks from our interactions with the system certificate store.  May be
+# worth reviewing our use of their API.
 LEAK
 name=http://code.google.com/p/drmemory/issues/detail?id=476 a
+KERNEL*.dll!LocalAlloc
 ...
-RPCRT4.dll!RpcBindingFromStringBindingW
-...
-NETAPI32.dll!DsRoleGetPrimaryDomainInformation
-...
-USERENV.dll!CreateEnvironmentBlock
-...
-CRYPT32.dll!CertOpenStore
-...
-CRYPT32.dll!CertCreateCertificateChainEngine
+CRYPT32.dll!CertGetCRLContextProperty
 
 LEAK
 name=http://code.google.com/p/drmemory/issues/detail?id=476 b
-KERNEL32.dll!LocalAlloc
+KERNEL*.dll!LocalAlloc
 ...
-CRYPT32.dll!CryptDecodeObjectEx
+CRYPT32.dll!CertAddCRLContextToStore
+
+LEAK
+name=http://code.google.com/p/drmemory/issues/detail?id=476 c
+KERNEL*.dll!LocalAlloc
 ...
-CRYPT32.dll!CertGetCRLContextProperty
+CRYPT32.dll!CertOpenStore
+
+LEAK
+name=http://code.google.com/p/drmemory/issues/detail?id=476 d
+RSAENH.dll!*
 ...
 CRYPT32.dll!CertGetCertificateChain
 
+LEAK
+name=http://code.google.com/p/drmemory/issues/detail?id=476 e
+RPCRT4.dll!*
+...
+CRYPT32.dll!CertGetCertificateChain
+
+LEAK
+name=http://code.google.com/p/drmemory/issues/detail?id=476 f
+KERNELBASE.dll!LocalAlloc
+SETUPAPI.dll!*
+...
+CRYPT32.dll!CertGetCertificateChain
+
+LEAK
+name=http://code.google.com/p/drmemory/issues/detail?id=476 g
+RPCRT4.dll!*
+RPCRT4.dll!*
+...
+CRYPT32.dll!CertCompareIntegerBlob
+
 UNINITIALIZED READ
 name=http://code.google.com/p/drmemory/issues/detail?id=511 a
 RPCRT4.dll!*
 ...
 RPCRT4.dll!UuidCreate
 ole32.dll!*
 
 UNINITIALIZED READ
 name=http://code.google.com/p/drmemory/issues/detail?id=511 b
 ole32.dll!*
@@ skipping 124 matching lines @@
 ntdll.dll!RtlpNtOpenKey
 ntdll.dll!RtlMakeSelfRelativeSD
 ntdll.dll!RtlAbsoluteToSelfRelativeSD
 ADVAPI32.dll!MakeSelfRelativeSD
 
 UNINITIALIZED READ
 name=http://crbug.com/TODO m
 ...
 CRYPT32.dll!I_CertSyncStore
 
-# This test intentionally leaks an object and checks that it's never deleted
+# WTF?
 LEAK
 name=http://crbug.com/TODO n
-...
-*!BrowserThreadTest_NotReleasedIfTargetThreadNonExistent_Test::TestBody
+KERNELBASE.dll!TlsSetValue
+RSAENH.dll!*
+RSAENH.dll!*
+
+# This matches the same stack as DrMem i#751, but it's an uninit read instead of
+# a leak.  Must be some early thread initialization.  Doesn't look like
+# bit-level though.
+UNINITIALIZED READ
+name=http://crbug.com/TODO o
+RPCRT4.dll!*
+RPCRT4.dll!*
+RPCRT4.dll!*
+ntdll.dll!*
+ntdll.dll!*
+KERNEL*.dll!BaseThreadInitThunk
 
 LEAK
 name=http://crbug.com/109278 video device COM leaks
 ...
 *!media::VideoCaptureDevice::*
 
 LEAK
 name=http://crbug.com/109278 audio device COM leaks
 ...
 *!GetInputDeviceNamesWin
@@ skipping 107 matching lines @@
 ntdll.dll!RtlLoadString
 
 # More bit manip fps
 UNINITIALIZED READ
 name=http://code.google.com/p/drmemory/issues/detail?id=493
 USP10.dll!ScriptPositionSingleGlyph
 
 ###############################################################
 # Benign issues in Chromium
 
+# This test intentionally leaks an object and checks that it's never deleted.
+LEAK
+name=BrowserThreadTest.NotReleasedIfTargetThreadNonExistant leak
+...
+*!BrowserThreadTest_NotReleasedIfTargetThreadNonExistent_Test::TestBody
+
 LEAK
 name=deliberate histogram leak
 ...
 *!operator new*
 ...
 *!*::*Histogram::FactoryGet
 
 LEAK
 name=deliberate LazyInstance leak
 ...
@@ skipping 72 matching lines @@
 *!ssl_InitSessionCacheLocks
 *!lock_cache
 *!ssl_LookupSID
 *!ssl2_BeginClientHandshake
 *!ssl_Do1stHandshake
 *!SSL_ForceHandshake
 *!net::SSL*SocketNSS::DoHandshake
 *!net::SSL*SocketNSS::DoHandshakeLoop
 
 LEAK
-name=http://crbug.com/74417
+name=http://crbug.com/74417 a
 *!operator new
 *!disk_cache::BackendImpl::CreateEntryImpl
 
 LEAK
-name=http://crbug.com/74425
+name=http://crbug.com/74417 b
 *!operator new
 *!disk_cache::BackendImpl::NewEntry
 
+# One more disk_cache::BackendImpl leak.  See also http://crbug.com/87500.
+LEAK
+name=http://crbug.com/74417 c
+*!operator new
+...
+*!disk_cache::EntryImpl::UserBuffer::UserBuffer
+
 LEAK
 name=http://crbug.com/75247
 ...
 *!operator new
 *!AutofillDownloadTestHelper::AutofillDownloadTestHelper
 
 LEAK
 name=http://crbug.com/78784
 *!generic_cpp_alloc
 *!operator new
@@ skipping 55 matching lines @@
 ...
 *!operator new
 *!views::NativeWidgetWin::OnCreate
 
 # Possible real Chromium issue in DoCrossfade.
 UNINITIALIZED READ
 name=http://crbug.com/110049
 *!media::DoCrossfade<*>
 *!media::Crossfade
 *!media::AudioRendererAlgorithmBase::FillBuffer
+
+# This is an NSS PRThread object installed in TLS.  Why isn't this detected as a
+# root?
+LEAK
+name=http://crbug.com/32624

[Timur Iskhodzhanov, 2012/02/09 10:50:18]

Might be worth filing a separate bug if you believe there should be a root.

[Reid Kleckner, 2012/02/09 15:17:37]

Yeah, I think there's some underlying issue.  You can search up and down this
file and in drmem's supps and see a bunch of tls related supps.  Created 778 to
cover this.

+*!PR_Calloc
+*!_PR_AttachThread
+*!_PRI_AttachThread