POSSIBLE LEAK: ntdll!RtlCriticalSectionList entries

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) 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 bytes
0x779b7eb9 ntdll.dll!RtlRunOnceBeginInitialize
??:0
0x779b42ea ntdll.dll!RtlInitializeCriticalSection
??:0
0x779bfd83 ntdll.dll!EtwRegisterTraceGuidsW
??:0
0x779bfd51 ntdll.dll!EtwRegisterTraceGuidsW
??:0
0x779bfba3 ntdll.dll!EtwRegisterTraceGuidsW
??:0
0x779bfb6f ntdll.dll!EtwRegisterTraceGuidsW
??:0
0x779b3070 ntdll.dll!RtlInterlockedFlushSList
??:0
0x0117c00b hello.exe!_calloc_impl
f:\dd\vctools\crt_bld\self_x86\crt\src\calloc_impl.c:94
0x0117496c hello.exe!_calloc_crt
f:\dd\vctools\crt_bld\self_x86\crt\src\crtheap.c:61
0x01173a2e hello.exe!_setenvp
f:\dd\vctools\crt_bld\self_x86\crt\src\stdenvp.c:127
0x770c3677 KERNEL32.dll!BaseThreadInitThunk
??:0
0x779b9f02 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!RtlpAllocateDebugInfo
??:0
0x77d542ea ntdll.dll!RtlInitializeCriticalSection
??:0
0x77d5fd83 ntdll.dll!RtlpInitializeLowFragHeap
??:0
0x77d5fd51 ntdll.dll!RtlpCreateLowFragHeap
??:0
0x77d5fba3 ntdll.dll!RtlpPerformHeapMaintenance
??:0
0x77d5fb6f ntdll.dll!RtlpAllocateHeap
??:0
0x77d53070 ntdll.dll!RtlAllocateHeap
??:0
0x77d738b2 ntdll.dll!RtlFlsAlloc
??:0
0x774e2e00 KERNELBASE.dll!FlsAlloc
??:0
0x00df4736 hello.exe!_mtinit
f:\dd\vctools\crt_bld\self_x86\crt\src\tidtable.c:385
0x75903677 KERNEL32.dll!BaseThreadInitThunk
??:0
0x77d59f02 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 =
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_