memory leak in TBB initialization routine (RML)

[romko]

Hi,

I've noticed that after upgrading to TBB 3.0_056, I become a memory leak report of 48 bytes in debug version of my software. I traced allocation spot which causes this leak - the callstack is:


> msvcr90d.dll!malloc(unsigned int nSize=48) Line 60 C++
msvcr90d.dll!operator new(unsigned int size=48) Line 59 + 0x9 bytes C++
irml_debug.dll!rml::internal::__RML_open_factory(rml::factory & f={...}, unsigned int & server_version=2, unsigned int client_version=2) Line 3247 + 0x1b bytes C++
tbb_debug.dll!tbb_factory::open() Line 74 + 0x1d bytes C++
tbb_debug.dll!governor::acquire_resources() Line 77 + 0xc bytes C++
tbb_debug.dll!__TBB_InitOnce::add_ref() Line 123 C++
tbb_debug.dll!tbb::internal::DllMain(unsigned long reason=1) Line 203 + 0x5 bytes C++
tbb_debug.dll!__DllMainCRTStartup(void * hDllHandle=0x00160000, unsigned long dwReason=1, void * lpreserved=0x0012fd24) Line 546 + 0x11 bytes C
tbb_debug.dll!_DllMainCRTStartup(void * hDllHandle=0x00160000, unsigned long dwReason=1, void * lpreserved=0x0012fd24) Line 510 + 0x11 bytes C
ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes
ntdll.dll!_LdrpRunInitializeRoutines@4() + 0x15d bytes
ntdll.dll!_LdrpInitializeProcess@8() + 0x7996 bytes
ntdll.dll!__LdrpInitialize@8() - 0x14eca bytes
ntdll.dll!_LdrInitializeThunk@8() + 0x10 bytes


Any way to avoid this leak?

My System: OS Vinwows Vista 32 bit, VS2008, TBB 3.0 056

Thanks!

[Andrey_Marochko]

Strictly speaking this not a conventional memory leak. RML (component that manages threads in TBB) pins itself in the process address space when its first loaded. And 48 bytes you see is its basic control structure that remains in memory until the process dies, and thus gets detected by the checker (BTW, which tool do you use?). Such a leak is harmless because it does not accumulate.

[romko]

hi Andrey,

Yes, I understand that this is not an "evil" memory leak ;) But still - absense of memory leaks in debug version is a software quality factor, so I am trying to stay "leak free". I use the usual MSVC's memory leak detection machinery (DEBUG_NEW). I blend other problematic spots away by temporarily disabling memory leak collection (_CrtSetDbgFlag), but this seems to be impossible if leak is produced during loading of statically linked DLLs.

On the side note - is it actually safe to leave out the whole RML stuff out my binary distribution as I don't use any mixery of TBB, OpenMP, etc. but rather only TBB?

Thanks!

[Alexey-Kukanov · Accepted solution]

Yes in this case you should not add RML to you distribution, unless maybeif you develop a library and want your users to have a choice of enabling shared RML.

[robiul_i_]

Like intel