Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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 ?
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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... :-)
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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.
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
OK, that should be useful to someone, but I can't make anything of it myself.
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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" miss due
to memory object that would be reused later, or a bug we've somehow missed.
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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" miss due to memory 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.
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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.
| |
Re: Memory leak from TBB when did nothing but only new/delete a task_scheduler_init.
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. :)
| | |
