TBB memory leak when used inside an MFC application

Question

Hi, stackoverflower,

Operating System: Windows 7 x64 SP1; TBB Version: 4.2.0; Compiler: Visual Studio 2012.

Description of the problem:

TBB removes memory leaks at the output of the MFC application. The same code does not clear any leaks when used from a simple command line. This seems like a problem loading the DLL. Due to the late unloading of tbb.dll, the debugger unloads some static variables as leaks.

Can anyone confirm this problem? Is there any work around?

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

Here is a memory dump:

Detected memory leaks! Dumping objects -> {608} normal block at 0x00457970, 36 bytes long. Data: <TBBW ork > 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: <TBBW ork > 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: <TBBW ork > 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: <TBBW ork > 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: <TBBW ork > 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: <TBBW ork > 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: <TBBW ork > 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: < HD ! > 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: <TBBW ork > 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: < ET! > 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: <TBBW ork > 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: <TBBW ork > 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: <TBBW ork > 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). 

Answer 1

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

If this is true, it would be better if Intel reported it, but warn that it would be possible to discuss it if it is really a real memory leak. We like to save zero reports of memory dumps in the output window, because soon you can not distinguish between real and harmless ones.