Possible leak of THREAD object in rpcrt4.dll!ThreadSelfHelper

_From [rnk@google.com](https://code.google.com/u/rnk@google.com/) on January 17, 2012 13:33:44_

This is a helper routine in rpcrt4.dll reached from many different entry points that allocates a THREAD object. Looking at the code, it seems like it gets installed into TLS or some other thread local root with a mid-chunk pointer. This issue covers fully investigating it so we know how it's reachable and if we can add heuristics to the tool to find it.

This leak has appeared in these other issues: https://code.google.com/p/drmemory/issues/detail?id=12&q=threadselfhelper https://code.google.com/p/drmemory/issues/detail?id=476&q=threadselfhelper https://code.google.com/p/drmemory/issues/detail?id=569&q=threadselfhelper Reports that I'm hitting currently on my workstation:

~~Dr.M~~ Error `#1`: POSSIBLE LEAK 196 direct bytes 0x00d4ad10-0x00d4add4 + 4148 indirect bytes
~~Dr.M~~ # 0 RPCRT4.dll!AllocWrapper
~~Dr.M~~ # 1 RPCRT4.dll!operator new
~~Dr.M~~ # 2 RPCRT4.dll!ThreadSelfHelper
~~Dr.M~~ # 3 RPCRT4.dll!RpcBindingFromStringBindingW
~~Dr.M~~ # 4 CFGMGR32.dll!PNP_HANDLE_bind
~~Dr.M~~ # 5 CFGMGR32.dll!PnPGetGlobalHandles
~~Dr.M~~ # 6 CFGMGR32.dll!CM_Get_Device_Interface_List_Size_ExW
~~Dr.M~~ # 7 SHELL32.dll!CMountPoint::_EnumVolumesNonPrimaryProcess
~~Dr.M~~ # 8 SHELL32.dll!CMountPoint::_InitLocalDriveHelperAsync
~~Dr.M~~ # 9 ntdll.dll!vsnprintf +0x180 (0x776694d2 )
~~Dr.M~~ `#10` ntdll.dll!TpCallbackIndependent +0x7db (0x776543e9 )
~~Dr.M~~ `#11` KERNEL32.dll!BaseThreadInitThunk
~~Dr.M~~ `#12` ntdll.dll!RtlInitializeExceptionChain +0x62 (0x77639ef2 )
~~Dr.M~~ `#13` ntdll.dll!RtlInitializeExceptionChain +0x35 (0x77639ec5 )
~~Dr.M~~
~~Dr.M~~ Error `#2`: POSSIBLE LEAK 196 direct bytes 0x00daee98-0x00daef5c + 0 indirect bytes
~~Dr.M~~ # 0 RPCRT4.dll!AllocWrapper
~~Dr.M~~ # 1 RPCRT4.dll!operator new
~~Dr.M~~ # 2 RPCRT4.dll!ThreadSelfHelper
~~Dr.M~~ # 3 RPCRT4.dll!RpcpSetThreadpoolCallbackInstance
~~Dr.M~~ # 4 RPCRT4.dll!PerformGarbageCollection
~~Dr.M~~ # 5 ntdll.dll!RtlIsCriticalSectionLockedByThread +0x4c9 (0x77654af3 )
~~Dr.M~~ # 6 ntdll.dll!TpCallbackIndependent +0x7db (0x776543e9 )
~~Dr.M~~ # 7 KERNEL32.dll!BaseThreadInitThunk
~~Dr.M~~ # 8 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x77639ef2 )
~~Dr.M~~ # 9 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x77639ec5 )

Neither AllocWrapper nor operator new seem to adjust the requested allocation size or return a mid-chunk pointer. AllocWrapper calls through HeapAlloc and calls some event logging code.

THREAD::THREAD (the ctor) does install itself into a TLS entry using this code:

RPCRT4!THREAD::THREAD+0x9f:
74d5de4a 64a118000000 mov eax,fs:[00000018] # Gets some struct in TLS
74d5de50 89b01c0f0000 mov [eax+0xf1c],esi # Roots itself, esi doesn't seem to be mid-chunk

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=751_