My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 306: POSSIBLE LEAK: ntdll!RtlCriticalSectionList entries
1 person starred this issue and may be notified of changes. Back to list
 
Project Member Reported by bruen...@google.com, Feb 24, 2011
the unaddr in i#301, once addressed, becomes a possible leak

Error #2: POSSIBLE LEAK 32 direct bytes 0x00cb8668-0x00cb8688 + 0 indirect bytes
0x779b7eb9 <ntdll.dll+0x37eb9> ntdll.dll!RtlRunOnceBeginInitialize
    ??:0
0x779b42ea <ntdll.dll+0x342ea> ntdll.dll!RtlInitializeCriticalSection
    ??:0
0x779bfd83 <ntdll.dll+0x3fd83> ntdll.dll!EtwRegisterTraceGuidsW
    ??:0
0x779bfd51 <ntdll.dll+0x3fd51> ntdll.dll!EtwRegisterTraceGuidsW
    ??:0
0x779bfba3 <ntdll.dll+0x3fba3> ntdll.dll!EtwRegisterTraceGuidsW
    ??:0
0x779bfb6f <ntdll.dll+0x3fb6f> ntdll.dll!EtwRegisterTraceGuidsW
    ??:0
0x779b3070 <ntdll.dll+0x33070> ntdll.dll!RtlInterlockedFlushSList
    ??:0
0x0117c00b <hello.exe+0xc00b> hello.exe!_calloc_impl
    f:\dd\vctools\crt_bld\self_x86\crt\src\calloc_impl.c:94    
0x0117496c <hello.exe+0x496c> hello.exe!_calloc_crt
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtheap.c:61    
0x01173a2e <hello.exe+0x3a2e> hello.exe!_setenvp
    f:\dd\vctools\crt_bld\self_x86\crt\src\stdenvp.c:127   
0x770c3677 <KERNEL32.dll+0x13677> KERNEL32.dll!BaseThreadInitThunk
    ??:0
0x779b9f02 <ntdll.dll+0x39f02> ntdll.dll!RtlInitializeExceptionChain
    ??:0

really the top frames are:
ntdll!RtlpAllocateDebugInfo+0x28:
ntdll!RtlInitializeCriticalSection+0x12:

on laptop have better symbols.
the 32 bytes == 0x20 is the same as the original unaddr where 8 bytes in is
stored on ntdll!RtlCriticalSectionList.  is it an extra header?

Error #1: POSSIBLE LEAK 32 direct bytes 0x00ca82a0-0x00ca82c0 + 0 indirect bytes
0x77d57eb9 <ntdll.dll+0x37eb9> ntdll.dll!RtlpAllocateDebugInfo
    ??:0
0x77d542ea <ntdll.dll+0x342ea> ntdll.dll!RtlInitializeCriticalSection
    ??:0
0x77d5fd83 <ntdll.dll+0x3fd83> ntdll.dll!RtlpInitializeLowFragHeap
    ??:0
0x77d5fd51 <ntdll.dll+0x3fd51> ntdll.dll!RtlpCreateLowFragHeap
    ??:0
0x77d5fba3 <ntdll.dll+0x3fba3> ntdll.dll!RtlpPerformHeapMaintenance
    ??:0
0x77d5fb6f <ntdll.dll+0x3fb6f> ntdll.dll!RtlpAllocateHeap
    ??:0
0x77d53070 <ntdll.dll+0x33070> ntdll.dll!RtlAllocateHeap
    ??:0
0x77d738b2 <ntdll.dll+0x538b2> ntdll.dll!RtlFlsAlloc
    ??:0
0x774e2e00 <KERNELBASE.dll+0x12e00> KERNELBASE.dll!FlsAlloc
    ??:0
0x00df4736 <hello.exe+0x4736> hello.exe!_mtinit
    f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c:385   
0x75903677 <KERNEL32.dll+0x13677> KERNEL32.dll!BaseThreadInitThunk
    ??:0
0x77d59f02 <ntdll.dll+0x39f02> ntdll.dll!__RtlUserThreadStart
    ??:0

        (0x00c86d50 points to mid-chunk 0x00ca82a8 in 0x00ca82a0-0x00ca82c0)
        is_vtable 0x00ca89f0: 2, 3

but there's no size in the header.
        (0x00d16d50 points to mid-chunk 0x00d382a8 in 0x00d382a0-0x00d382c0)
        (0x00d389f4 points to mid-chunk 0x00d382a8 in 0x00d382a0-0x00d382c0)

0:000> dd d382a0
00d382a0  00000000 00d1aaa8 00d389f0 00d16d50

to identify would want to walk this doubly-linked list,
but ntdll!RtlCriticalSectionList is not exported:

0:000> dd ntdll!RtlCriticalSectionList L4
77e20168  77e24348 00d38ab0 77e20170 77e20170
0:000> dd 00d38ab0 L4
00d38ab0  77e20168 00d38a78 00000000 00000000
0:000> dd 00d38a78 L4
00d38a78  00d38ab0 00d38a40 00000000 00000000
0:000> dd 00d38a40 L4
00d38a40  00d38a78 00d389f0 00000000 00000000
0:000> dd 00d389f0 L4
00d389f0  00d38a40 00d382a8 00000000 00000000
0:000> dd 00d382a8 L4
00d382a8  00d389f0 00d16d50 00000000 00000000

prior 8 bytes:
0:000> dd ntdll!RtlCriticalSectionList-8 L4
77e20160  77e20160 77e20160 77e24348 00d38ab0
0:000> dd 00d38ab0-8 L4
00d38aa8  00000000 01080048 77e20168 00d38a78
0:000> dd 00d38a78-8 L4
00d38a70  00000000 00f90aa4 00d38ab0 00d38a40
0:000> dd 00d38a40-8 L4
00d38a38  00000000 00f90a64 00d38a78 00d389f0
0:000> dd 00d389f0-8 L4
00d389e8  00000000 00f90a24 00d38a40 00d382a8
0:000> dd 00d382a8-8 L4
00d382a0  00000000 00d1aaa8 00d389f0 00d16d50

walking backward from RtlCriticalSectionList:
77e24340 ntdll!RtlCriticalSectionLock_DEBUG = <no type information>
0:000> dd 77e24348-8 L4
77e24340  00000000 77e220d8 77e24368 77e20168
0:000> dd 77e24368-8 L4
77e24360  00000000 77e220c0 77e24908 77e24348
0:000> ln 77e220d8
(77e220d8)   ntdll!RtlCriticalSectionLock   |  (77e24340)   ntdll!RtlCriticalSectionLock_DEBUG
Exact matches:
    ntdll!RtlCriticalSectionLock = <no type information>
0:000> ln 77e220c0
(77e220c0)   ntdll!LdrpLoaderLock   |  (77e220d8)   ntdll!RtlCriticalSectionLock
Exact matches:
    ntdll!LdrpLoaderLock = <no type information>

proposal:
add to default suppression:

POSSIBLE LEAK
...
ntdll.dll!RtlInitializeCriticalSection

that covers both machines' callstacks.
if someone allocates a crit sec and loses all pointers, should get true
leak, so shouldn't cause false neg.

Feb 24, 2011
Project Member #1 derek.br...@gmail.com
This issue was closed by revision r191.
Status: Fixed
Jan 17, 2012
Project Member #2 rnk@google.com
Looks like we have another code path that can create this possible leak:
http://build.chromium.org/p/client.drmemory/builders/win-vista_x64-drm/builds/1683/steps/dbg%20full%20app_suite_tests/logs/stdio

~~Dr.M~~ Error #3: POSSIBLE LEAK 32 direct bytes 0x00d5dee8-0x00d5df08 + 0 indirect bytes
~~Dr.M~~ # 0 ntdll.dll!RtlInitOutOfProcessMemoryStream             +0x87     (0x77e3081d <ntdll.dll+0x7081d>)
~~Dr.M~~ # 1 ntdll.dll!RtlInitializeCriticalSectionAndSpinCount    +0x18     (0x77e19ec5 <ntdll.dll+0x59ec5>)
~~Dr.M~~ # 2 RPCRT4.dll!?                                          +0x0      (0x7757046f <RPCRT4.dll+0x1046f>)
~~Dr.M~~ # 3 RPCRT4.dll!RpcBindingSetAuthInfoExW                   +0x44c    (0x7757fec5 <RPCRT4.dll+0x1fec5>)
~~Dr.M~~ # 4 RPCRT4.dll!RpcBindingSetAuthInfoExW                   +0x3cf    (0x7757fe48 <RPCRT4.dll+0x1fe48>)
~~Dr.M~~ # 5 RPCRT4.dll!RpcBindingSetAuthInfoExW                   +0x331    (0x7757fdaa <RPCRT4.dll+0x1fdaa>)
~~Dr.M~~ # 6 RPCRT4.dll!NdrConformantStringMemorySize              +0x7e3    (0x77580983 <RPCRT4.dll+0x20983>)
~~Dr.M~~ # 7 RPCRT4.dll!NdrConformantStringMemorySize              +0x765    (0x77580905 <RPCRT4.dll+0x20905>)
~~Dr.M~~ # 8 RPCRT4.dll!UuidCreate                                 +0x662    (0x775771dd <RPCRT4.dll+0x171dd>)
~~Dr.M~~ # 9 RPCRT4.dll!I_RpcGetBuffer                             +0xe      (0x775761b4 <RPCRT4.dll+0x161b4>)
~~Dr.M~~ #10 RPCRT4.dll!NdrGetBuffer                               +0x2d     (0x77577631 <RPCRT4.dll+0x17631>)
~~Dr.M~~ #11 RPCRT4.dll!?                                          +0x0      (0x77610120 <RPCRT4.dll+0xb0120>)

Seems reasonable to me to add a suppression of:

POSSIBLE LEAK
name=default i#306 (critical section 8-byte-in pointer)
...
ntdll.dll!RtlInitializeCriticalSectionAndSpinCount
Status: Accepted
Jan 17, 2012
Project Member #3 rnk@google.com
Hm, I can't decide if this is the same issue or if it should be separately considered under issue 385.

On the one hand, this is basically the same report described in this issue: a 32-byte possible leak with a mid-chunk root from RtlInitializeCriticalSection(AndSpinCount).  On the other hand, the report looks slightly different, which could just be from different versions of Windows, ie 7 vs Vista.
Sign in to add a comment

Powered by Google Project Hosting