Visual studio 2012 detects memory leak in TBB

[Zenju]

Hi,

I'm on Windows 7 x64, Visual C++ Express 2012 Update 1, Win7.1 SDK platform, C++ 32 bit, debug build, using TBB for VC10:

When running the debug build, Visual Studio shows a number of memory leaks which after analysis were created by the TBB library. My original scenario has been rather complex, but after meticulous refactoring I was able to produce a minimal sample. I have an additional dependence to wxWidgets, an open source framework, which seems to have something to do with the leak (I suspect it's an indirect influence on the dll loading order). For some reason the combination of statically linking both wxWidgets debug dll and TBB dll causes the leak, without wxWidgets everything is fine.

On my machine I am able to consitently reproduce the behavior. So please let me know if I can help to debug this issue.

The test program is very short, so I present it here in total:

[cpp]#include <tbb/task_scheduler_init.h>
#include <tbb/parallel_for.h>

class __declspec(dllimport) wxStringBase
{
public:
wxStringBase() ;//
};

int gnaz = 0;

int main()
{
  if (gnaz != 0)
new wxStringBase;

tbb::task_scheduler_init scheduler;

tbb::parallel_for(tbb::blocked_range<int>(0, 100, 2),
[=](const tbb::blocked_range<int>& r)
{
});

return 0;
}[/cpp]

The sole purpose of the " __declspec" is to trigger static dll linkage to the wxWidgets debug library. Without this dummy class the leak is not reproducible. Also if I remove the "parallel_for" there is no leak.

Additionally I have attached the complete VS 2012 project. To get consistent results I found it is necessary to do a full project rebuild (CTRL+ALT+F7), even after changing a single file only, else, the leak is not always reproducible.

 So my question is: Is this a real leak? If not: how can the VS 2012 runtime be "pacified" to not show these messages? I cannot simply ignore the leak detector because it is an essential debugging feature. On the other hand the mere usage of TBB currently renders the leak detector useless by flooding debug messages for "leaks" that are triggered by TBB allocations.

 Best, Zenju

 Here is the debug log after program exit:

'ScalerTest.exe' (Win32): Loaded 'C:\Users\ZenJu\Desktop\ScalerTest\BUILD\ScalerTest.exe'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntdll.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Program Files\C++\wxWidgets\lib\vc10_x86_debug_dll\wxbase28ud_vc_custom.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\user32.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\gdi32.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\lpk.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\usp10.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcrt.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\advapi32.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sechost.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sspicli.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cryptbase.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\shell32.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\shlwapi.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ole32.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcr100d.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Users\ZenJu\Desktop\ScalerTest\BUILD\tbb_debug.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcp100d.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\imm32.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msctf.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\guard32.dll'. Cannot find or open the PDB file.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\version.dll'. Symbols loaded.
'ScalerTest.exe' (Win32): Loaded 'C:\Windows\SysWOW64\fltLib.dll'. Symbols loaded.
The thread 0x1a1c has exited with code 0 (0x0).
The thread 0x19d4 has exited with code 0 (0x0).
The thread 0x504 has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
{309} normal block at 0x00A2DE98, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{308} normal block at 0x00A2DCD8, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{307} normal block at 0x00A2DB18, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{306} normal block at 0x00A2D958, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{305} normal block at 0x00A2D798, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{304} normal block at 0x00A2D5D8, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{303} normal block at 0x00A2D418, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{302} normal block at 0x00A2D248, 404 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{301} normal block at 0x00A2D1E8, 36 bytes long.
Data: <T B B W o r k > 54 00 42 00 42 00 20 00 57 00 6F 00 72 00 6B 00
{300} normal block at 0x00A2D028, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{299} normal block at 0x00A2B3E0, 28 bytes long.
Data: < > 00 00 00 00 E8 D1 A2 00 04 05 00 00 00 00 00 00
{298} normal block at 0x00A2CE68, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{297} normal block at 0x00A2CCA8, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{296} normal block at 0x00A2CAE8, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{295} normal block at 0x00A2C928, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{294} normal block at 0x00A2C768, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{293} normal block at 0x00A2B210, 404 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{292} normal block at 0x00A2B1B0, 36 bytes long.
Data: <T B B W o r k > 54 00 42 00 42 00 20 00 57 00 6F 00 72 00 6B 00
{291} normal block at 0x00A2B158, 28 bytes long.
Data: < > 00 00 00 00 B0 B1 A2 00 1C 1A 00 00 00 00 00 00
{277} normal block at 0x00A2ADD8, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{270} normal block at 0x00A2A188, 384 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{269} normal block at 0x00A2A140, 8 bytes long.
Data: < > AC 9F A2 00 00 00 00 00
{268} normal block at 0x00A2A0F8, 8 bytes long.
Data: <, > 2C 9F A2 00 00 00 00 00
{267} normal block at 0x00A2A0B0, 8 bytes long.
Data: < > AC 9E A2 00 00 00 00 00
{266} normal block at 0x00A2A068, 8 bytes long.
Data: <, > 2C 9E A2 00 00 00 00 00
{265} normal block at 0x00A29E28, 516 bytes long.
Data: < h > 04 00 00 00 68 A0 A2 00 00 00 00 00 00 00 00 00
{264} normal block at 0x00A29DE0, 8 bytes long.
Data: <L > 4C 9C A2 00 00 00 00 00
{263} normal block at 0x00A29D98, 8 bytes long.
Data: < > CC 9B A2 00 00 00 00 00
{262} normal block at 0x00A29D50, 8 bytes long.
Data: <L > 4C 9B A2 00 00 00 00 00
{261} normal block at 0x00A29D08, 8 bytes long.
Data: < > CC 9A A2 00 00 00 00 00
{260} normal block at 0x00A29AC8, 516 bytes long.
Data: < > 04 00 00 00 08 9D A2 00 00 00 00 00 00 00 00 00
{259} normal block at 0x00A29A80, 8 bytes long.
Data: < > EC 98 A2 00 00 00 00 00
{258} normal block at 0x00A29A38, 8 bytes long.
Data: <l > 6C 98 A2 00 00 00 00 00
{257} normal block at 0x00A299F0, 8 bytes long.
Data: < > EC 97 A2 00 00 00 00 00
{256} normal block at 0x00A299A8, 8 bytes long.
Data: <l > 6C 97 A2 00 00 00 00 00
{255} normal block at 0x00A29768, 516 bytes long.
Data: < > 04 00 00 00 A8 99 A2 00 00 00 00 00 00 00 00 00
{254} normal block at 0x00A28FA8, 1920 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{253} normal block at 0x00A28D68, 512 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{252} normal block at 0x00A28C80, 168 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{251} normal block at 0x00A28B40, 260 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
The program '[5228] ScalerTest.exe' has exited with code 0 (0x0).

[Zenju]

Hi, I updated the test case, including a wxWidgets lib and clearing all unnecessary dependencies to boost. It is now fully self-contained. Additional info: I'm using the latest stable TBB v4.1, update 1 Regards, Zenju

[Vladimir_P_1234567890]

Hello, you need to use Intel(R) Inspector to find out whether these are real memory leaks or false positives. --Vladimir

[Zenju]

I do not own Intel Inspector and have actually never used it before. So I downloaded and installed the 30 day trial an ran it over the sample test case. It is finding a number of leaks and a few other problems. I've attached the results.

[Zenju]

I refined the Inspector settings and included the wxWidgets source and symbol paths. It looks like the resource leaks are static objects within .dlls that are not destructed.

[Zenju]

So nobody has an idea what is going wrong or what I could try? I suspect an issue with the dll unloading order. Isn't this supposed to be solved automatically when linking all dlls statically? Or is there something I need to watch out for?

[SergeyKostrov]

>>...you need to use Intel(R) Inspector to find out whether these are real memory leaks or false positives... No, the user 'Zenju' doesn't need to use an additional tool because Microsoft's memory leaks detection CRT-based API is a very safisticated tool and it did a great job as we can see. Vladimir, did you try to run his test-case? There are actually two memory leaks related problems in the test-case provided by the user 'Zenju': - Some memory leaks in the TBB library ( please believe me ), and - An incomplete use of a C++ operator 'new': ... int main() { wxStringBase *pwxSbObj = NULL; if (gnaz != 0) pwxSbObj = ( wxStringBase * )new wxStringBase; tbb::task_scheduler_init scheduler; tbb::parallel_for(tbb::blocked_range(0, 100, 2), [=](const tbb::blocked_range& r) { }); if( pwxSbObj != NULL ) delete pwxSbObj; return 0; }

[SergeyKostrov]

>>...So nobody has an idea what is going wrong or what I could try? I suspect an issue with the dll unloading order. Isn't this supposed to >>be solved automatically when linking all dlls statically? Or is there something I need to watch out for? Memory leaks problems are never solved automatically unless there is a special memory leaks detection software subsystem in some application or a garbage collector, like in Java. I'll take a look at your test-case more better tomorrow ( sorry, I did a very quick verification now... ).

[Zenju]

Thanks a lot Sergey for helping out! At least C++ isn't going to be boring even if you think you've seen a lot of MT-related problems. Generally I have only two explanations for the test case: 1. TBB has serious memory leaks in the most trivial usage scenario. Then I wonder why nobody has detected it before. 2. TBB has no "definite" memory leak, but the DLL unloading order has the CRT memory leak detection run before TBB dll unloading, and thereby static object destruction. What I meant with "solved automatically" is that I expect the C++ compiler to automatically detect dependencies in statically (!) linked dlls and loads and unloads the dlls in the right order. Since TBB depends on CRT, I would expect the compiler to unload TBB *before* CRT, latter of which internally calls "_CrtDumpMemoryLeaks()". So this case 2 should actually not occur. Let me just stress the most important point: At the end of the day, I really don't care if TBB has a real or not so real memory leak. Even if TBB would not care about this issue and just *hide* the problem by somehow silencing the CRT memory detection, I would be *fine*! For me as a developer, TBB is outside my domain knowledge and I don't nor should I care about it's internals - that's not my job. However what I *do* care about is being able to use my tools. One of them is the CRT memory leak detection. Currently TBB is showing me memory leaks, and no matter if they are "real" or not, I cannot ignore these messages. That's the real problem. So the "solution" is to either fix this memory leak in TBB if there is one - otherwise adapt TBB to not trigger this "false leak" in the CRT leak detector anymore.

[SergeyKostrov]

Hi everybody, Let me go through all your statements because you're right and I appreciate your response. >>Generally I have only two explanations for the test case: >>1. TBB has serious memory leaks in the most trivial usage scenario. Then I wonder why nobody has detected it before. That is correct. Unfortunately, TBB is highly over-complecated library. I know about some memory leaks and also another resource problems for more than 1 year. >>2. TBB has no "definite" memory leak, but the DLL unloading order has the CRT memory leak detection run before >>TBB dll unloading, and thereby static object destruction. This is by design of Microsoft's Memory Leaks Detection ( MLD ) CRT-based API. Note: Microsoft's MLD is NOT portable and it doesn't produce identical outputs on Desktop and Windows CE / Windows Mobile platforms. I hope that some time in January 2013 I will look at how it works on a 64-bit Windows platform. >>What I meant with "solved automatically" is that I expect the C++ compiler to automatically detect dependencies in statically (!) linked >>dlls and loads and unloads the dlls in the right order. Since TBB depends on CRT, I would expect the compiler to unload >>TBB *before* CRT... When you're debugging can you see in 'Output' window of Visual Studio 2012 a list of unloaded DLLs? I can't see it with Visual Studios 2005 & 2008 for Desktop applications. I can see it with Visual Studios 2005 & 2008 for Windows CE / Windows Mobile applications. Even here there is some inconsistency with Visual Studios. >>Let me just stress the most important point: At the end of the day, I really don't care if TBB has a real or not so real memory leak. >>Even if TBB would not care about this issue and just *hide* the problem by somehow silencing the CRT memory detection, >>I would be *fine*! For debug configurations Microsoft re-defines a 'malloc' function with a 'malloc_dbg' function. You can re-define it again and you won't see any memory leaks in 'Output' window. >>For me as a developer, TBB is outside my domain knowledge and I don't nor should I care about it's internals - that's not >>my job. However what I *do* care about is being able to use my tools. One of them is the CRT memory leak detection. >>Currently TBB is showing me memory leaks, and no matter if they are "real" or not, I cannot ignore these messages. Here is an incomplete example that demonstrates how I control Microsoft's MLD: ... #define CrtMemoryLeaksDetectionOn() \ { \ _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); \ _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_DEBUG ); \ } #define CrtMemoryLeaksDetectionOff() \ { \ _CrtSetDbgFlag( 0 ); \ } #define CrtMemoryLeaksReport() \ { \ _CrtDumpMemoryLeaks(); \ } ... >>That's the real problem. >>So the "solution" is to either fix this memory leak in TBB if there is one - otherwise adapt TBB to not trigger this "false leak" >>in the CRT leak detector anymore. My opinion in that case is as follows: It won't be fixed.

[SergeyKostrov]

[EDITED] That was a duplicate of the previous post. Instead of it here is a new comment: >>I have an additional dependence to wxWidgets, an open source framework, which seems to have something to do with >>the leak ( I suspect it's an indirect influence on the dll loading order )... A loading order of DLLs doesn't influence on memory leaks because memory leaks occur in an application when some API ( implemented in a DLL and already loaded ) was executed. However, it is possible to create memory leaks on DLL_PROCESS_ATTACH or DLL_PROCESS_DETACH in a DllMain function of some DLL.

[Zenju]

When you're debugging can you see in 'Output' window of Visual Studio 2012 a list of unloaded DLLs?

This is what puzzles me: I do see unloaded dlls in the output window (the log in the first post is what I'm getting for the test case), but only for dynamically linked dlls (FreeLibrary), but not for statically linked ones. Since it's unlikely Microsoft just forgot to unload latter dlls it seems as if this info is just not shown. I'm on Desktop Win7x64 using the most recent VS2012 Update1. Are you able to reproduce the test case?

You can re-define it again and you won't see any memory leaks in 'Output' window.

But then I won't see my own memory leaks neither? The problem is similar to using a messy library which only compiles cleanly on level 1 warning while my own code compiles clean even at level 4. Sure I could reduce warning level to 1 for the complete project, but then I cannot enfore the higher standards towards my own code anymore. However in this case it needs to be clarified if it is a "false leak" first - if it's a bug it must not be hidden, but fixed! I had enough adventures in "undefined behavior land" already.

Here is an incomplete example that demonstrates how I control Microsoft's MLD:

This is exactly what happens in my test case. You don't see it, but the wxWidgets library in a static object's constructor of the dll enables the CRT MLD. To be 100% clear, what wxWidgets sets is "_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF )", which strictly speaking is not correct according to MS documentation since it disables the "_CRTDBG_ALLOC_MEM_DF". However the MLD is obviously still working fine.

A loading order of DLLs doesn't influence on memory leaks

I am referring to the classic problem when "_CrtDumpMemoryLeaks()" is called before certain destructors ran (assuming they do run latter, otherwise this *is* a leak). Since "_CrtDumpMemoryLeaks" is called by the CRT, there must not be any other dll unloading afterwards, which will execute static object destructors of these dlls. I don't know if this is the problem here, If I knew I wouldn't ask for help.

My opinion in that case is as follows: It won't be fixed.

I would find that quite sad. Not fixing reported bugs, not even investigating them, is what gives software development support in general a bad name. On the other hand it gives the "more reactive" kind of support the chance to shine while providing the most trivial of help. You'd be surprised how much positive feedback I get when I fix reported bugs of my users - this is not for being brilliant and fast in fixing (well often I'm fast), but most of the time for fixing bugs at all. Damn we need higher standards in software quality. Sorry for the OT rant :)

[SergeyKostrov]

>>...I'm on Desktop Win7x64 using the most recent VS2012 Update1. Are you able to reproduce the test case? I don't have Visual Studio 2012. Here is a list of what I use: - Visual Studio 2005 Professional Edition ( used by default on a project I'm working on ) - Visual Studio 2008 Professional Edition - Visual Studio 2008 Express Edition - Visual Studio 2010 Express Edition It doesn't matter if I will try to use your test-case with VS 2008s and VS 2010 because I know memory leaks will be reproduced since TBB version will be the same. >>>>... >>>>My opinion in that case is as follows: It won't be fixed. >> >>...I would find that quite sad. Not fixing reported bugs, not even investigating them... Many years ago I detected a memory leaks in MFC library and it is not fixed even if I reported to Microsoft. A short response from a guy blamed me for not using MFC in a right way. Of course, who else could be blaimed for this?

[SergeyKostrov]

And one more note. When I'm investigating what is wrong with some codes I try to create as cleaner as possible test-case. It means that in your case you need to do a couple of more verifications, like: [ Test-Case 1 ] int main() { return 0; } [ Test-Case 2 ] #include *tbb/task_scheduler_init.h* #include *tbb/parallel_for.h* int main() { return 0; } [ Test-Case 3 ] #include *tbb/task_scheduler_init.h* #include *tbb/parallel_for.h* int main() { tbb::task_scheduler_init scheduler; tbb::parallel_for(tbb::blocked_range( 0, 100, 2 ), [=](const tbb::blocked_range& r) { }); return 0; } [ Test-Case 4 ] #include *Some WxWidget Headers* int main() { return 0; } [ Test-Case 5 ] #include *Some WxWidget Headers* int main() { //... // Some WxWidget functionality //... return 0; } An idea is simple: I don't make any conclusions until all test-cases are verified and as usual it is the most time consuming part.

[Zenju]

Many years ago I detected a memory leaks in MFC library and it is not fixed even if I reported to Microsoft. A short response from a guy blamed me for not using MFC in a right way. Of course, who else could be blaimed for this?

He probably is paid no matter if he helps you or not. However in latter case he'll have much less trouble. That's a general problem of how to get employees to take responsibility for a product... But let's not bash on MS: I sent bug reports to certain MS employees directly per email and they instantly analyzed and included the fixes in their next release. Often it comes down to who you are asking for support - asking the right people makes a world of difference compared to "official" bug trackers.

When I'm investigating what is wrong with some codes I try to create as cleaner as possible test-case.

I have already tested all variations. If I make the test case any more simpler I cannot reproduce the memory leak anymore. *Anyway the question is who is going to solve this?* It cannot be me, since I have no commit rights into TBB. Additionally I do not have deeper knowledge of TBB internals, so it doesn't make sense for me to spend further time on this. Usually an *Intel developer* would take over at this point and analyze what is currently a *trivial* test case - all that's needed to be done is to download the zip file and double-click on the sln file, then press F7. I don't see how I could provide this in an even simpler format for "support" to consume. But I have to admit that I am not a paying Intel customer. So it seems I am just getting the support I have payed for. Fine, but why pretend there is a free bug report forum when problems are ignored? Better take a stand and close it down instead of wasting "invested" developer's time!

[SergeyKostrov]

>>...I have already tested all variations. If I make the test case any more simpler I cannot reproduce the memory leak anymore... I see. >>...But I have to admit that I am not a paying Intel customer... Me too and also I'm not Intel employee. Please try to contact an Intel Premium Support however I don't know if TBB related problems will be considered. TBB is an Open Source project and Intel representative could ask for a contribution from you.

[SergeyKostrov]

>>... >>'ScalerTest.exe' (Win32): Loaded 'C:\Program Files\C++\wxWidgets\lib\vc10_x86_debug_dll\wxbase28ud_vc_custom.dll'. Symbols >>loaded. >>... I think all reported memory leaks ( see post #1 ) are from wxbase28ud_vc_custom.dll. I have NOT detected any memory leaks in TBB for a modified Test-Case #3: [ Test-Case 3 ] #include *tbb/task_scheduler_init.h* #include *tbb/parallel_for.h* void main( void ) { tbb::task_scheduler_init ts( 16 ); }

[Zenju]

The memory leaks in my test case are definitively from both wxWidgets and TBB which Intel Inspector and CRT MLD show. Just because the symptoms of the bug don't show up in a modified test case doesn't mean there is no problem anymore, it's quite possible the bug is merely hidden. So the question is "who is responsible for the leaks in my test case?". - Maybe wxWidgets has some buggy behavior that "corrupts" TBB to leak, which would not under normal circumstances. - Or it's me, I setup something in the wrong way (although the testcase is basically trivial). - Or there is in fact a TBB leak which does only show under certain circumstances. To solve this riddle, ideally someone with deep knowledge of TBB would analyze this *wink at intel* - he could at least explain why TBB leaks in the test case.

[Zenju]

The memory leaks in my test case are definitively from both wxWidgets and TBB which Intel Inspector and CRT MLD show. Just because the symptoms of the bug don't show up in a modified test case doesn't mean there is no problem anymore, it's quite possible the bug is merely hidden. So the question is "who is responsible for the leaks in my test case?". - Maybe wxWidgets has some buggy behavior that "corrupts" TBB to leak, which would not under normal circumstances. - Or it's me, I setup something in the wrong way (although the testcase is basically trivial). - Or there is in fact a TBB leak which does only show under certain circumstances. To solve this riddle, ideally someone with deep knowledge of TBB would analyze this *wink at intel* - he could at least explain why TBB leaks in the test case.

[SergeyKostrov]

>>...- Maybe wxWidgets has some buggy behavior that "corrupts" TBB to leak... That is simply NOT possible. Period. >>...Or it's me, I setup something in the wrong way (although the testcase is basically trivial)... I already explained that you need to ISOLATE COMPLETELY test cases for TBB and wxWidgets libraries. They should NOT have any dependencies on each other. Understand? >>...- Or there is in fact a TBB leak which does only show under certain circumstances... Your test-case to verify TBB is not clean and you need to remove dependencies on wxbase28ud_vc_custom.dll. That is, an import library must be deleted from project settings at: 'Configuration Properties' -> 'Linker' -> 'General' -> 'Additional Dependencies' >>...To solve this riddle, ideally someone with deep knowledge of TBB would analyze this *wink at intel* - he could at least explain why >>TBB leaks in the test case... There are NO any memory leaks for the clean Test-Case #3 ( two posts above ) that doesn't have any dependencies on 3rd party DLLs. Good Luck!

[Zenju]

That is simply NOT possible. Period.

Nonsense, of course it's "possible".

need to ISOLATE COMPLETELY test cases

There is no reason to change the test case in any way. It is reproducing the symptoms in its current form *and* it is minimal.

There are NO any memory leaks for the clean Test-Case

This is irrelevant since it's a *different* test case.