POSSIBLE LEAK: ntdll!RtlCriticalSectionList entries #306
Comments
|
From derek.br...@gmail.com on February 24, 2011 21:16:02 This issue was closed by revision r191 . Status: Fixed |
|
From rnk@google.com on January 17, 2012 09:49:22 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 Seems reasonable to me to add a suppression of: POSSIBLE LEAK Status: Accepted |
|
From rnk@google.com on January 17, 2012 10:58:42 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. |
From bruen...@google.com on February 24, 2011 13:26:50
the unaddr in issue #301, once addressed, becomes a possible leak
Error
#2: POSSIBLE LEAK 32 direct bytes 0x00cb8668-0x00cb8688 + 0 indirect bytes0x779b7eb9 <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 bytes0x77d57eb9 <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
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 =
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 =
0:000> ln 77e220c0
(77e220c0) ntdll!LdrpLoaderLock | (77e220d8) ntdll!RtlCriticalSectionLock
Exact matches:
ntdll!LdrpLoaderLock =
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.
Original issue: http://code.google.com/p/drmemory/issues/detail?id=306
The text was updated successfully, but these errors were encountered: