From [email protected] on July 25, 2011 06:55:09

As of r410 , the reports look like this:

[W7]
Error #1: LEAK 264 direct bytes 0x00873c60-0x00873d68 + 0 indirect bytes
0x753e8442 <ole32.dll+0x48442> ole32.dll!LockEntry::ThreadInit // !CoRevokeInitializeSpy w/o symbols
0x753e84a6 <ole32.dll+0x484a6> ole32.dll!CRWLock::ThreadInit // !CoRevokeInitializeSpy
0x753e85ea <ole32.dll+0x485ea> ole32.dll!COleTls::TLSAllocData // !CoRevokeInitializeSpy
0x753b7226 <ole32.dll+0x17226> ole32.dll!CoInitialize
0x0040101b <test.exe+0x101b> test.exe!main
test.cpp:8

Error #2: POSSIBLE LEAK 24 direct bytes 0x00873d80-0x00873d98 + 0 indirect bytes
0x753e0248 <ole32.dll+0x40248> ole32.dll!EventPoolEntry::operator new // !CoTaskMemRealloc
0x753e0287 <ole32.dll+0x40287> ole32.dll!EventPoolEntry::CreatePoolEntry // !CoTaskMemRealloc
0x753e035d <ole32.dll+0x4035d> ole32.dll!EventPoolEntry::ThreadInit // !CoTaskMemRealloc
0x753e84b5 <ole32.dll+0x484b5> ole32.dll!CRWLock::ThreadInit // !CoRevokeInitializeSpy
0x753e85ea <ole32.dll+0x485ea> ole32.dll!COleTls::TLSAllocData // !CoRevokeInitializeSpy
0x753b7226 <ole32.dll+0x17226> ole32.dll!CoInitialize
0x0040101b <test.exe+0x101b> test.exe!main
test.cpp:8

Error #3: POSSIBLE LEAK
// CreateFontIndirectW, see issue #17 , issue #60 ----
[XP32]
Error #1-8: UNINITIALIZED READ: reading register ebx // caused by uninit random number? [ issue #65 ]
@0:00:01.360 in thread 7192
0x77e76*** <RPCRT4.dll+0x6***> RPCRT4.dll!rc4_key // !UuidCreate w/o symbols
0x77e76265 <RPCRT4.dll+0x6265> RPCRT4.dll!UuidCreate
0x77501459 <ole32.dll+0x21459> ole32.dll!wCoCreateGuid // !CoCreateGuid
0x775018d2 <ole32.dll+0x218d2> ole32.dll!CObjectContext::CreateObjectContext // !CoInitializeEx
0x77501691 <ole32.dll+0x21691> ole32.dll!InitThreadCtx // !CoInitializeEx
0x775015fb <ole32.dll+0x215fb> ole32.dll!wCoInitializeEx // !CoInitializeEx
0x77501539 <ole32.dll+0x21539> ole32.dll!CoInitializeEx
0x7752f959 <ole32.dll+0x4f959> ole32.dll!CoInitialize
0x0040101b <test.exe+0x101b> test.exe!main
test.cpp:8

Error #9: POSSIBLE LEAK
// CreateFontIndirectW, see issue #17 , issue #60

Summary: False reports from CoInitialize

from drmemory.

From [email protected] on July 27, 2011 03:13:56

the XP UNINITs filed as issue #511

Summary: False leak reports from CoInitialize

from drmemory.

From [email protected] on January 06, 2012 11:02:13

These CoInitialize leaks look related to https://code.google.com/p/chromium/issues/detail?id=109278 , I'm investigating.

I think we can remove the CoInitialize_/CoCreateInstace_ uninit suppressions from t/v/drm/suppressions_full.txt now; they don't show up for me.

My first guess at these leaks from TLSAllocData is that they are allocated and rooted into the TEB, but sometime during shutdown the link from the TEB to these objects is severed, either by setting the TLS entry to NULL, or if there is some indirect array in the library, it is freed and the objects rooted in its entries are not.

If so, it's a native Windows bug and we should suppress.

Owner: [email protected]
Labels: Component-LeakCheck

from drmemory.

From [email protected] on January 06, 2012 12:16:05

Here's my analysis of the CreatePoolEntry leak:

ole32!EventPoolEntry::CreatePoolEntry:
7501f0d7 8bff mov edi,edi
7501f0d9 55 push ebp
7501f0da 8bec mov ebp,esp
7501f0dc 51 push ecx
7501f0dd 53 push ebx
7501f0de 56 push esi
7501f0df 8b350415fe74 mov esi,[ole32!_imp__CreateEventW (74fe1504)]
7501f0e5 57 push edi
7501f0e6 33ff xor edi,edi
7501f0e8 57 push edi
7501f0e9 57 push edi
7501f0ea 6a01 push 0x1
7501f0ec 57 push edi
7501f0ed ffd6 call esi
7501f0ef 8945fc mov [ebp-0x4],eax
7501f0f2 3bc7 cmp eax,edi
7501f0f4 744d jz ole32!EventPoolEntry::CreatePoolEntry+0x34 (7501f143)

ole32!EventPoolEntry::CreatePoolEntry+0x1f:
7501f0f6 57 push edi
7501f0f7 57 push edi
7501f0f8 57 push edi
7501f0f9 57 push edi
7501f0fa ffd6 call esi
7501f0fc 8bd8 mov ebx,eax
7501f0fe 3bdf cmp ebx,edi
7501f100 0f8478540700 je ole32!EventPoolEntry::CreatePoolEntry+0x2b (7509457e)

ole32!EventPoolEntry::CreatePoolEntry+0x2b:
7509457e ff75fc push dword ptr [ebp-0x4]
75094581 ff152413fe74 call dword ptr [ole32!_imp__CloseHandle (74fe1324)]
75094587 e9b7abf8ff jmp ole32!EventPoolEntry::CreatePoolEntry+0x34 (7501f143)

ole32!EventPoolEntry::CreatePoolEntry+0x34:
7501f143 33c0 xor eax,eax
7501f145 ebf5 jmp ole32!EventPoolEntry::CreatePoolEntry+0x7e (7501f13c)

ole32!EventPoolEntry::CreatePoolEntry+0x38:
7501f106 6a18 push 0x18
7501f108 e8abffffff call ole32!PrivateMemAlloc (7501f0b8) # LEAK: tail calls operator new
7501f10d 3bc7 cmp eax,edi # null check, falls through
7501f10f 7436 jz ole32!EventPoolEntry::CreatePoolEntry+0x52 (7501f147) # not taken

ole32!EventPoolEntry::CreatePoolEntry+0x43: # Call EventPoolEntry ctor
7501f111 53 push ebx
7501f112 ff75fc push dword ptr [ebp-0x4]
7501f115 8bc8 mov ecx,eax
7501f117 e834000000 call ole32!EventPoolEntry::EventPoolEntry (7501f150)
7501f11c 8bf0 mov esi,eax

ole32!EventPoolEntry::CreatePoolEntry+0x54: # null check after ctor
7501f11e 3bf7 cmp esi,edi
7501f120 0f8466540700 je ole32!EventPoolEntry::CreatePoolEntry+0x58 (7509458c) # not taken

ole32!EventPoolEntry::CreatePoolEntry+0x68: # Check some arg
7501f126 397d08 cmp [ebp+0x8],edi
7501f129 740f jz ole32!EventPoolEntry::CreatePoolEntry+0x7c (7501f13a) # Not taken

ole32!EventPoolEntry::CreatePoolEntry+0x6d:
7501f12b 8d460c lea eax,[esi+0xc] # MID-CHUNK lea
7501f12e 50 push eax
7501f12f 68986b1275 push 0x75126b98 # global list head
7501f134 ff156c13fe74 call dword ptr [ole32!_imp__InterlockedPushEntrySList (74fe136c)]

ole32!EventPoolEntry::CreatePoolEntry+0x7c:
7501f13a 8bc6 mov eax,esi # Put new obj in ret val

ole32!EventPoolEntry::CreatePoolEntry+0x7e: # Cleanup, ret
7501f13c 5f pop edi
7501f13d 5e pop esi
7501f13e 5b pop ebx
7501f13f c9 leave
7501f140 c20400 ret 0x4

Untaken error paths:

ole32!EventPoolEntry::CreatePoolEntry+0x52: # Error path, not taken
7501f147 33f6 xor esi,esi
7501f149 ebd3 jmp ole32!EventPoolEntry::CreatePoolEntry+0x54 (7501f11e)

ole32!EventPoolEntry::CreatePoolEntry+0x58: # Error path, not executed
7509458c ff75fc push dword ptr [ebp-0x4]
7509458f 8b352413fe74 mov esi,[ole32!_imp__CloseHandle (74fe1324)]
75094595 ffd6 call esi
75094597 53 push ebx
75094598 ffd6 call esi
7509459a e9a4abf8ff jmp ole32!EventPoolEntry::CreatePoolEntry+0x34 (7501f143)

Also, running with loglevel 3 shows that there is a mid-chunk pointer from a global:

defined range 0x75126000-0x7512a000
0x75126504 points to chunk 0x00371b00-0x00371b68
0x75126514 points to chunk 0x003719f0-0x00371aa8
0x75126518 points to chunk 0x00371930-0x003719e8
(0x75126b98 points to mid-chunk 0x0037822c in 0x00378220-0x00378238)
mid=0x00354d6c, top=0x00000000
is_vtable 0x00354d6c: 2, 3
string length=0x0, capacity=0x0, alloc=0x18
0x75127208 points to chunk 0x0036ea48-0x0036ea68

It also says this doesn't point to a vtable. Looking at the ctor, it doesn't look like it's initializing a vptr member either.

IMO this one should just be suppressed. I'll investigate the other leak now.

from drmemory.

From [email protected] on January 09, 2012 08:34:15

The other leak looks like a true one time leak. I wrote a client to try to trace out the relevant TLS calls in ole32.dll and got the following trace:

Running main() from gtest_main.cc
Note: Google Test filter = Ole*
[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from OleTest
[ RUN ] OleTest.CoInitialize
pre COleTls::TLSAllocData
pre CRWLock::ThreadInit
pre LockEntry::ThreadInit
post LockEntry::ThreadInit
ret: 0x00c64d70
post CRWLock::ThreadInit
ret: 0x00c64d70
pre TLSAddToMap
arg1: 0x00c64c48
post TLSAddToMap
post COleTls::TLSAllocData
pre ProcessUninitTlsCleanup
post ProcessUninitTlsCleanup
[ OK ] OleTest.CoInitialize (565 ms)
[ RUN ] OleTest.CoInitializeEx
pre ProcessUninitTlsCleanup
post ProcessUninitTlsCleanup
[ OK ] OleTest.CoInitializeEx (40 ms)
[----------] 2 tests from OleTest (664 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (742 ms total)
[ PASSED ] 2 tests.

YOU HAVE 1 DISABLED TEST

pre CleanupTlsMap
pre CleanupTlsState
pre TLSRemoveFromMap
arg1: 0x00c64c48
post TLSRemoveFromMap
post CleanupTlsState
post CleanupTlsMap
all done

From the above it looks like LockEntry::ThreadInit allocates some pool of locks, and then one is stored some tls map. LockEntry::ThreaCleanup looks like it will do the corresponding free of the pool, but it is never called at process end, and all references to the pool are lost during finalization. IMO this is a true, one-time-per-process leak, and we should suppress it.

from drmemory.

From [email protected] on January 10, 2012 12:50:42

This issue was closed by revision r701 .

Status: Fixed

from drmemory.

From [email protected] on January 10, 2012 13:24:18

This will still show up on other versions of Windows or other patch levels, so I'm going to leave this open to cover suppressing these leaks there. Also see issue #741 for ideas on how to write better suppressions.

Status: Accepted
Labels: -Priority-Medium Priority-Low

from drmemory.