TBB memory leaks when using inside of MFC applicat

Hello stackoverflower,

Operation system: Windows 7 x64 SP1; TBB version: 4.2.0; Compiler: Visual Studio 2012.

Problem description:

TBB dumps memory leaks on the exit of MFC application. The same code doesn't dump any leaks, when used from simple command line program. It looks like a DLL unload order problem. Due to late tbb.dll unloading the debuger dumps some static variables as leaks.

Can someone confirm this issue? Is there any work around?

I also posted this question to Intel forum. There you can find the both test applications: command line and MFC.

Here is the memory dump:

Detected memory leaks!
Dumping objects ->
{608} normal block at 0x00457970, 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
{607} normal block at 0x00457918, 28 bytes long.
 Data: <    pyE         > 00 00 00 00 70 79 45 00 98 0F 00 00 00 00 00 00
{605} normal block at 0x0044ED98, 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
{590} normal block at 0x00450AD8, 28 bytes long.
 Data: <      D         > 00 00 00 00 98 ED 44 00 04 20 00 00 00 00 00 00
{583} normal block at 0x00455AD8, 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
{582} normal block at 0x00455A80, 28 bytes long.
 Data: <     ZE  .      > 00 00 00 00 D8 5A 45 00 98 2E 00 00 00 00 00 00
{580} normal block at 0x00455860, 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
{579} normal block at 0x00455808, 28 bytes long.
 Data: <    `XE         > 00 00 00 00 60 58 45 00 EC 18 00 00 00 00 00 00
{569} normal block at 0x00453EC8, 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
{568} normal block at 0x00453E70, 28 bytes long.
 Data: <     >E  0      > 00 00 00 00 C8 3E 45 00 FC 30 00 00 00 00 00 00
{566} normal block at 0x00453C50, 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
{565} normal block at 0x0044D338, 28 bytes long.
 Data: <    P<E         > 00 00 00 00 50 3C 45 00 D8 08 00 00 00 00 00 00
{546} normal block at 0x0044F248, 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
{536} normal block at 0x00451128, 28 bytes long.
 Data: <    H D  !      > 00 00 00 00 48 F2 44 00 14 21 00 00 00 00 00 00
{531} normal block at 0x00450518, 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
{530} normal block at 0x004504C0, 28 bytes long.
 Data: <      E T!      > 00 00 00 00 18 05 45 00 54 21 00 00 00 00 00 00
{528} normal block at 0x00450290, 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
{527} normal block at 0x00450238, 28 bytes long.
 Data: <      E 8       > 00 00 00 00 90 02 45 00 38 18 00 00 00 00 00 00
{518} normal block at 0x0044EE68, 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
{517} normal block at 0x0044EE10, 28 bytes long.
 Data: <    h D  2      > 00 00 00 00 68 EE 44 00 B0 32 00 00 00 00 00 00
{507} normal block at 0x0044B190, 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
{505} normal block at 0x0044D3B0, 28 bytes long.
 Data: <      D  '      > 00 00 00 00 90 B1 44 00 18 27 00 00 00 00 00 00
Object dump complete.
The program '[12168] TbbMfcTest.exe: Native' has exited with code 0 (0x0).

If you spy the TBB sources, it seems that TBB allocates a memory block without proper releasing it (i.e. market::create_one_job() allocates a name for h->nameW with _wcsdup(name)).

If this is indeed the case, it would be best if one reports this to Intel but be warned that one might get into a discussion if this is indeed a true memory leak. We like to keep zero memory dump reports in the output window, because soon one can't distinguish the real ones with the harmless ones.