- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Disclaimer: I am quite new to parallel theory and implementation
(Also I am using the Visual Leak Detector http://vld.codeplex.com/)
I recently started from scratch on a Win32 application where every component would be managed in a task scheduler. The first thing I decided to do was create a window and message handler task. I know this isn't exactly parallel-worthy, but I want to keep a consistent design where every component is a task, even if it doesn't have sub-tasks.
I run this code and the window is created fine and the message handler works - but I also get 10 memory leaks detected.
Any help is greatly appreciated. These may not be harmful leaks, but I just want to make sure I'm starting this on the right foot.
(Also I am using the Visual Leak Detector http://vld.codeplex.com/)
I recently started from scratch on a Win32 application where every component would be managed in a task scheduler. The first thing I decided to do was create a window and message handler task. I know this isn't exactly parallel-worthy, but I want to keep a consistent design where every component is a task, even if it doesn't have sub-tasks.
I run this code and the window is created fine and the message handler works - but I also get 10 memory leaks detected.
[cpp]int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)Each callstack looks the same, except for a different number of "tbb::task_scheduler_int::default_num_threads" lines.
{
// Allocate our window task
WindowTask& windowTask = *new(task::allocate_root()) WindowTask(hInstance, 640, 480, L"Window Title");
// Spawn task
task::spawn_root_and_wait(windowTask);
Sleep(1000);
return 0;
}[/cpp]
[plain]---------- Block 118 at 0x00378E60: 188 bytes ----------
Call Stack:
0x100095CA (File and line number not available): tbb::internal::NFS_Free
0x10009559 (File and line number not available): tbb::internal::NFS_Allocate
0x10017FB6 (File and line number not available): tbb::task_scheduler_init::default_num_threads
0x1001884D (File and line number not available): tbb::task_scheduler_init::default_num_threads
0x100177F1 (File and line number not available): tbb::task_scheduler_init::default_num_threads
0x1001185E (File and line number not available): tbb::internal::get_initial_auto_partitioner_divisor
0x100112CB (File and line number not available): tbb::internal::allocate_root_proxy::allocate
c:\threaded bb\tbb30_20100915oss\include\tbb\task.h (797): operator new
c:\documents and settings\trunk\main.cpp (28): WinMain
f:\sp\vctools\crt_bld\self_x86\crt\src\crtexe.c (589): __tmainCRTStartup
f:\sp\vctools\crt_bld\self_x86\crt\src\crtexe.c (414): WinMainCRTStartup
0x7C817077 (File and line number not available): RegisterWaitForInputIdle[/plain]
Any help is greatly appreciated. These may not be harmful leaks, but I just want to make sure I'm starting this on the right foot.
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well... not sure why this happens (I thought this was called automatically?) but when I manually initiate the task scheduler I don't get any memory leaks :\
tbb::task_scheduler_init init;
tbb::task_scheduler_init init;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Indeed when using tbb::task_scheduler_init to explicitly delimit the lifetime of TBB scheduler you cannot see the leak because the one you saw in the original variant was a false positive.
There, allocating the first task triggered TBB scheduler auto-initialization. And in this case its lifetime stretches until the thread completion point, that is until after all static objects destructors are executed. At the same time most of the leak detectors check heap snapshots exactly by means of a static object destructor. Since TBB scheduler caches memory used for task allocation, the combination of the above factors obviously results in a false positive.
There, allocating the first task triggered TBB scheduler auto-initialization. And in this case its lifetime stretches until the thread completion point, that is until after all static objects destructors are executed. At the same time most of the leak detectors check heap snapshots exactly by means of a static object destructor. Since TBB scheduler caches memory used for task allocation, the combination of the above factors obviously results in a false positive.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page