From 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 <ntdll.dll+0x694d2>)
Dr.M #10 ntdll.dll!TpCallbackIndependent +0x7db (0x776543e9 <ntdll.dll+0x543e9>)
Dr.M #11 KERNEL32.dll!BaseThreadInitThunk
Dr.M #12 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x77639ef2 <ntdll.dll+0x39ef2>)
Dr.M #13 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x77639ec5 <ntdll.dll+0x39ec5>)
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 <ntdll.dll+0x54af3>)
Dr.M # 6 ntdll.dll!TpCallbackIndependent +0x7db (0x776543e9 <ntdll.dll+0x543e9>)
Dr.M # 7 KERNEL32.dll!BaseThreadInitThunk
Dr.M # 8 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x77639ef2 <ntdll.dll+0x39ef2>)
Dr.M # 9 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x77639ec5 <ntdll.dll+0x39ec5>)

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