Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.

[tommy_developer]

The following sample code will cause memory leaks:

//
// create a new TBB task scheduler, the leaked bytes varies with the number of threads !!
//
tbb::task_scheduler_init *pScheduler = new tbb::task_scheduler_init(4);

//
// do nothing
//

//
// terminate the scheduler
//
pScheduler->terminate();

//
// delete the pointer
//
delete pScheduler;

If the parameter is 1, then no leaks. Will TBB deal with this situation in the future ?

[RafSchietekat]

What hardware/O.S./compiler, what TBB version, what memory allocator, did you redirect new/delete? How did you verify that it is indeed a leak, how big is it, and does it grow if you repeat the code? Why did you allocate it dynamically instead of on the stack and why do you explicitly call terminate()? Questions, questions... :-)

[tommy_developer]

Quoting - Raf Schietekat

What hardware/O.S./compiler, what TBB version, what memory allocator, did you redirect new/delete? How did you verify that it is indeed a leak, how big is it, and does it grow if you repeat the code? Why did you allocate it dynamically instead of on the stack and why do you explicitly call terminate()? Questions, questions... :-)

Windows/VC 9, TBB 2.1, it leaks even with one code line tbb::task_scheduler_init oScheduler(2). The leaked bytes varies with the number of threads which is the parameter passed to ctor of tbb::task_scheduler_init: 1 - 0 bytes, 2 - 384 bytes, 3 - 32 bytes,4 - 48 bytes, etc.

[RafSchietekat]

OK, that should be useful to someone, but I can't make anything of it myself.

[Alexey-Kukanov]

Quoting - tommy_developer

Windows/VC 9, TBB 2.1, it leaks even with one code line tbb::task_scheduler_init oScheduler(2). The leaked bytes varies with the number of threads which is the parameter passed to ctor of tbb::task_scheduler_init: 1 - 0 bytes, 2 - 384 bytes, 3 - 32 bytes,4 - 48 bytes, etc.

0) Is it "vanilla" TBB 2.1, or some update?
1) How do you determine there is a leak? Some tool tells you perhaps?
2) If you put the TBB initialization into a long loop, will the memory use grow consistently? Will the tool report a proportional increase in the number of leaked objects and amount of memory ?

We do test TBB for memory leaks. Thus I am trying to understand whether your issue might be a tool false positive, a "perceived" missdue tomemory object that would be reused later, or a bug we've somehow missed.

[tommy_developer]

Quoting - Alexey Kukanov (Intel)

0) Is it "vanilla" TBB 2.1, or some update?
1) How do you determine there is a leak? Some tool tells you perhaps?
2) If you put the TBB initialization into a long loop, will the memory use grow consistently? Will the tool report a proportional increase in the number of leaked objects and amount of memory ?

We do test TBB for memory leaks. Thus I am trying to understand whether your issue might be a tool false positive, a "perceived" missdue tomemory object that would be reused later, or a bug we've somehow missed.

0) Yes, it is"vanilla" TBB 2.1.
1) Use the CRT Debugger APIs, turn on the memory leak checking bit.
2) No, it will not grow.

These are the code for enabling CRT Debugger memory leak checking:

//
// set the report mode to be file and debugger's output window
//
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );

//
// pass the stdout stream to it
//
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );

//
// get the current flag
//
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );

//
// turn on leak checking bit
//
tmpFlag |= _CRTDBG_LEAK_CHECK_DF;

//
// turn off _CRT_BLOCK checking bit
//
tmpFlag &= ~_CRTDBG_CHECK_CRT_DF;

//
// set flag to the new value
//
_CrtSetDbgFlag( tmpFlag );

Copy the above code before the code line "tbb::task_scheduler_init oScheduler(2);" and use "Start Debugging (F5)" or "Start Without Debugging (Ctrl + F5)" in Visual Studio to reproduce this.

[Alexey-Kukanov]

Quoting - tommy_developer

0) Yes, it is"vanilla" TBB 2.1.
1) Use the CRT Debugger APIs, turn on the memory leak checking bit.
2) No, it will not grow.

Thank you for the information and the code; it made it easier for me to reproduce the behavior.

I could ensure you that there is no real memory leaks. The reason why CRT debug heap reports some is that the TBB worker threads shut down asynchronously; i.e. the main application thread does not wait for them to complete. As the result, the final heap checks are performed earlier than worker threads destroy all their objects.

It is partially proved by the fact that putting TBB initializer in a loop does not increase the amount of "leaks". If you want more evidence, put a delay (e.g. Sleep for a second) in main() after all task_scheduler_init objects are destroyed (e.g. after the loop), and check if the CRT diagnostics still remain.

[tommy_developer]

Quoting - Alexey Kukanov (Intel)

Thank you for the information and the code; it made it easier for me to reproduce the behavior.

I could ensure you that there is no real memory leaks. The reason why CRT debug heap reports some is that the TBB worker threads shut down asynchronously; i.e. the main application thread does not wait for them to complete. As the result, the final heap checks are performed earlier than worker threads destroy all their objects.

It is partially proved by the fact that putting TBB initializer in a loop does not increase the amount of "leaks". If you want more evidence, put a delay (e.g. Sleep for a second) in main() after all task_scheduler_init objects are destroyed (e.g. after the loop), and check if the CRT diagnostics still remain.

I have tried your suggestion, now CRT diagnose no leaks. :)