task_scheduler_init object causes memory leak in VS2008

[Rob_Ottenhoff]

Hi,

Since I switched to VS2008 I get a memory leak report from VS2008 in every tbb application I run. The object itself is cleaned up, but apperently VS2008 thinks it allocates some memory that is never freed. Is this true ? If so : can intel fix it, please ? If not : how can I get rid of the wrongful report ?

Regards,

Rob

[Alexey-Kukanov]

Hi Rob,

First of all, how did you get the memory leak report? Did you use _CrtDumpMemoryLeaks() and related stuff?

If yes, you might be call it too early, before the destructor of task_scheduler_init was run. To avoid this, you might either createan additional scope inside main() and put creation of task_scheduler_init inside this scope while keeping )_CrtDumpMemoryLeaks outside of it. Thus you ensure that deinitialization of the library has completed when you check for the leaks. Another way, which MSDN recommends to use if you have multiple return paths, and which also works with TBB, is to not call _CrtDumpMemoryLeaks() at the end but instead call _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); in the beginning of the program. In this case, the check is done automatically at program exit, and it is done late enough to run all TBB destructors.

I tested my above proposals with one of our examples and confirm they work for the case where the task_scheduler_init object is created inside main(). If this object is created at file scope, the first approach is obviously not applicable, but the second one (_CrtSetDbgFlag) worked just fine for me.

If your memory leak report is obtained by some other way, please elaborate more on how you got the memory leak report.

[Rob_Ottenhoff]

Quoting - Alexey Kukanov (Intel)

Hi Rob,

First of all, how did you get the memory leak report? Did you use _CrtDumpMemoryLeaks() and related stuff?

If yes, you might be call it too early, before the destructor of task_scheduler_init was run. To avoid this, you might either createan additional scope inside main() and put creation of task_scheduler_init inside this scope while keeping )_CrtDumpMemoryLeaks outside of it. Thus you ensure that deinitialization of the library has completed when you check for the leaks. Another way, which MSDN recommends to use if you have multiple return paths, and which also works with TBB, is to not call _CrtDumpMemoryLeaks() at the end but instead call _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); in the beginning of the program. In this case, the check is done automatically at program exit, and it is done late enough to run all TBB destructors.

I tested my above proposals with one of our examples and confirm they work for the case where the task_scheduler_init object is created inside main(). If this object is created at file scope, the first approach is obviously not applicable, but the second one (_CrtSetDbgFlag) worked just fine for me.

If your memory leak report is obtained by some other way, please elaborate more on how you got the memory leak report.

Hi Alexey,

Thank you for your answer. In the end I used _CrtSetDbgFlag to turn of memory checking for the allocation of the task_scheduler_init objects. ( and to turn it back on immediately thereafter ).

Regards,

Rob