True system leaks in RtlpUpdateTEBLanguage reached through setupapi.dll!_CRT_INIT

[derekbruening]

From rnk@google.com on January 17, 2012 16:37:59

Splitting these leaks out from issue #12 :

Error #6: LEAK 12 direct bytes 0x0031a1b0-0x0031a1bc + 0 indirect bytes
0x77a91862 <ntdll.dll+0x51862> ntdll.dll!LdrpSearchResourceSection_U
0x77a9c481 <ntdll.dll+0x5c481> ntdll.dll!LdrpGetRcConfig
0x77a818de <ntdll.dll+0x418de> ntdll.dll!LdrIsResItemExist
0x77a8175e <ntdll.dll+0x4175e> ntdll.dll!LdrpSearchResourceSection_U
0x77a83e5f <ntdll.dll+0x43e5f> ntdll.dll!RtlLoadString
0x76364095 <KERNELBASE.dll+0x14095> KERNELBASE.dll!LoadStringBaseExW
0x773a7c2b <USER32.dll+0x17c2b> USER32.dll!LoadStringW
0x75f4c3c6 <SETUPAPI.dll+0xc3c6> SETUPAPI.dll!MyLoadString
0x75f49829 <SETUPAPI.dll+0x9829> SETUPAPI.dll!MemoryInitializeEx
0x75f4cdaf <SETUPAPI.dll+0xcdaf> SETUPAPI.dll!ProcessAttach
0x75f4cc65 <SETUPAPI.dll+0xcc65> SETUPAPI.dll!DllMain
0x75f41875 <SETUPAPI.dll+0x1875> SETUPAPI.dll!_CRT_INIT
0x77a79960 <ntdll.dll+0x39960> ntdll.dll!LdrpCallInitRoutine
0x77a7d8c9 <ntdll.dll+0x3d8c9> ntdll.dll!LdrpRunInitializeRoutines
0x77a7d78c <ntdll.dll+0x3d78c> ntdll.dll!LdrpLoadDll
0x77a7c4e5 <ntdll.dll+0x3c4e5> ntdll.dll!LdrLoadDll
0x76362288 <KERNELBASE.dll+0x12288> KERNELBASE.dll!LoadLibraryExW
0x763622e5 <KERNELBASE.dll+0x122e5> KERNELBASE.dll!LoadLibraryExA
0x7652a2b6 <SHELL32.dll+0x7a2b6> SHELL32.dll!__delayLoadHelper2
0x764ffb61 <SHELL32.dll+0x4fb61> SHELL32.dll!_tailMerge_SETUPAPI_dll
0x76500365 <SHELL32.dll+0x50365> SHELL32.dll!CMountPoint::_InitLocalDriveHelperAsync
0x77aa8746 <ntdll.dll+0x68746> ntdll.dll!RtlpTpWorkCallback
0x77a85504 <ntdll.dll+0x45504> ntdll.dll!TppWorkerThread
0x75623677 <KERNEL32.dll+0x13677> KERNEL32.dll!BaseThreadInitThunk
0x77a79f02 <ntdll.dll+0x39f02> ntdll.dll!__RtlUserThreadStart
0x77a79ed5 <ntdll.dll+0x39ed5> ntdll.dll!_RtlUserThreadStart

Error #7: LEAK 8 direct bytes 0x0031b818-0x0031b820 + 0 indirect bytes
0x77a9179e <ntdll.dll+0x5179e> ntdll.dll!RtlpUpdateTEBLanguage
0x77a91757 <ntdll.dll+0x51757> ntdll.dll!InitializeTEBUserLangList
0x77a9100a <ntdll.dll+0x5100a> ntdll.dll!RtlGetThreadPreferredUILanguages
0x77a9dc37 <ntdll.dll+0x5dc37> ntdll.dll!LdrpSetThreadPreferredLangList
0x77a83ca4 <ntdll.dll+0x43ca4> ntdll.dll!LdrpLoadResourceFromAlternativeModule
0x77a837dc <ntdll.dll+0x437dc> ntdll.dll!LdrpSearchResourceSection_U
0x77a83e5f <ntdll.dll+0x43e5f> ntdll.dll!RtlLoadString
0x76364095 <KERNELBASE.dll+0x14095> KERNELBASE.dll!LoadStringBaseExW
0x773a7c2b <USER32.dll+0x17c2b> USER32.dll!LoadStringW
0x75f4c3c6 <SETUPAPI.dll+0xc3c6> SETUPAPI.dll!MyLoadString
0x75f49829 <SETUPAPI.dll+0x9829> SETUPAPI.dll!MemoryInitializeEx
0x75f4cdaf <SETUPAPI.dll+0xcdaf> SETUPAPI.dll!ProcessAttach
0x75f4cc65 <SETUPAPI.dll+0xcc65> SETUPAPI.dll!DllMain
0x75f41875 <SETUPAPI.dll+0x1875> SETUPAPI.dll!_CRT_INIT
0x77a79960 <ntdll.dll+0x39960> ntdll.dll!LdrpCallInitRoutine
0x77a7d8c9 <ntdll.dll+0x3d8c9> ntdll.dll!LdrpRunInitializeRoutines
0x77a7d78c <ntdll.dll+0x3d78c> ntdll.dll!LdrpLoadDll
0x77a7c4e5 <ntdll.dll+0x3c4e5> ntdll.dll!LdrLoadDll
0x76362288 <KERNELBASE.dll+0x12288> KERNELBASE.dll!LoadLibraryExW
0x763622e5 <KERNELBASE.dll+0x122e5> KERNELBASE.dll!LoadLibraryExA
0x7652a2b6 <SHELL32.dll+0x7a2b6> SHELL32.dll!__delayLoadHelper2
0x764ffb61 <SHELL32.dll+0x4fb61> SHELL32.dll!_tailMerge_SETUPAPI_dll
0x76500365 <SHELL32.dll+0x50365> SHELL32.dll!CMountPoint::_InitLocalDriveHelperAsync
0x77aa8746 <ntdll.dll+0x68746> ntdll.dll!RtlpTpWorkCallback
0x77a85504 <ntdll.dll+0x45504> ntdll.dll!TppWorkerThread
0x75623677 <KERNEL32.dll+0x13677> KERNEL32.dll!BaseThreadInitThunk
0x77a79f02 <ntdll.dll+0x39f02> ntdll.dll!__RtlUserThreadStart
0x77a79ed5 <ntdll.dll+0x39ed5> ntdll.dll!_RtlUserThreadStart

I can reproduce these as well with any shell32.dll usage. It looks like shell32.dll needs to load setupapi.dll, which is done on a new thread. Eventually we end up in these leaf functions, which store data into the TEB:

ntdll!RtlpUpdateTEBLanguage+0x1d:
77644913 8b4030 mov eax,[eax+0x30]
77644916 6a08 push 0x8
77644918 6a08 push 0x8
7764491a ff7018 push dword ptr [eax+0x18]
7764491d e82497feff call ntdll!RtlAllocateHeap (7762e046)
77644922 8bf0 mov esi,eax
77644924 3bf3 cmp esi,ebx
77644926 0f84527d0400 je ntdll!RtlpUpdateTEBLanguage+0x32 (7768c67e)

fallthrough

ntdll!RtlpUpdateTEBLanguage+0x39:
7764492c 64a118000000 mov eax,fs:[00000018]
77644932 891e mov [esi],ebx
77644934 895e04 mov [esi+0x4],ebx
77644937 89b0bc0f0000 mov [eax+0xfbc],esi # Rooted here

From issue #12 comment 6:

This needs further investigation to see who is supposed to be freeing it that isn't. For now I think these are true leaks that occur once per thread created this way. Only I'm not sure how exactly the thread is getting created, or I would try to create a minimal test case

Original issue: http://code.google.com/p/drmemory/issues/detail?id=753

[derekbruening]

From rnk@google.com on January 17, 2012 13:48:40

We should investigate how the second thread is terminated. It might be worth hooking into thread termination so we can use its TEB during the reachability scan at shutdown. This might hide serious leaks in a program that repeatedly starts threads and stores something into the TEB that is leaked. Most large applications try to avoid spawning more than a constant number of threads and try to terminate them all cleanly before process exit, though, so I think this behavior may be desirable.