- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I rencently updated my development environment from Intel C++ Studio XE 2013 Beta to the release version. This new version comes with TBB 4.1, and now the application I've been working on for over a year decides to lockup when closing. Such behavior did not occur with previous versions of TBB, up to the version released along with the Beta (initial release, as I did not update it afterwards while still in Beta).
It may be worth noting that what makes use of TBB is a COM DLL. When DllMain is called with DLL_PROCESS_ATTACH, a static pointer to a task_scheduler_init is initialized. When DllMain is called with DLL_PROCESS_DETACH, the pointer is deleted. The deletion is where things start to go wrong now.
Here's the call stack up to the locking place:
> tbb_debug.dll!tbb::internal::binary_semaphore::V() Line 91 + 0x11 bytes C++
tbb_debug.dll!rml::internal::thread_monitor::notify() Line 186 C++
tbb_debug.dll!tbb::internal::rml::private_worker::start_shutdown() Line 241 + 0xb bytes C++
tbb_debug.dll!tbb::internal::rml::private_server::request_close_connection(bool __formal) Line 186 + 0x11 bytes C++
tbb_debug.dll!tbb::internal::market::release() Line 139 C++
tbb_debug.dll!tbb::internal::market::try_destroy_arena(tbb::internal::market * m, tbb::internal::arena * a, unsigned int aba_epoch, bool master) Line 212 C++
tbb_debug.dll!tbb::internal::arena::on_thread_leaving<1>() Line 343 + 0x13 bytes C++
tbb_debug.dll!tbb::internal::generic_scheduler::cleanup_master() Line 1109 C++
tbb_debug.dll!tbb::internal::governor::terminate_scheduler(tbb::internal::generic_scheduler * s) Line 167 C++
tbb_debug.dll!tbb::task_scheduler_init::terminate() Line 308 + 0x9 bytes C++
dllname.dll!tbb::task_scheduler_init::~task_scheduler_init() Line 111 C++
dllname.dll!tbb::task_scheduler_init::`scalar deleting destructor'() + 0x16 bytes C++
What's also worth noting is that the issue does not seem to occur if no TBB function in particular is called (like parallel_for).
I hope you can shed some light into this serious issue.
Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anton Malakhov (Intel) wrote:I just tested, and it deadlocks in release mode as well.Another question, does it deadlock in debug configuration only?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anton Malakhov (Intel) wrote:I have added an issue report at the Premier Support website with the same title as this topic, in which there is a way to reproduce it. I would rather not put the link information to download the application here in the forums.
we cannot reliably observe the problem in our tests, thus would appreciate your help in making a reproducer..
Anton Malakhov (Intel) wrote:I will be checking it then once the new version is released. Regards, Paúl.
Meanwhile, we will disable the usage of SRWLocks in the next Update 1 release. We hope, it will help until the root cause is identified and fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
binksoftware wrote:I tried to reproudce the hang you mentioned here by compiling the TBB tests with 4.1 headers and running them with 4.0U5 DLL. Unfortunately, I was not able to reproduce any hang. Could you give us a bit more information regarding the nature of your application? In particular, we would like to know what TBB constructs the application uses. That will help us understand the cause of the problem: whether the problem is due to the API changes from 4.0U5 to 4.1 or it is due to a bug in the TBB release and the TBB tests need be extended. Thank you very much
I also tried compiling the DLL with TBB 4.1, but using the TBB 4.0 Update 5 DLL (tbb_debug.dll). It is even worse as the application hangs during normal use. It was a long shot, and it had all chances of failing anyway.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wooyoung Kim (Intel) wrote:The program uses tbb::atomic (mostly for reference counting), tbb::spin_mutex for (occasional) locking and the parallel_for and parallel_do template functions. The program also uses the scalable_malloc and scalable_free functions for memory allocation of objects and containers. I don't recall using anything else. Regards, Paúl.
I tried to reproudce the hang you mentioned here by compiling the TBB tests with 4.1 headers and running them with 4.0U5 DLL.
Unfortunately, I was not able to reproduce any hang. Could you give us a bit more information regarding the nature of your application?
In particular, we would like to know what TBB constructs the application uses. That will help us understand the cause of the problem: whether the problem is due to the API changes from 4.0U5 to 4.1 or it is due to a bug in the TBB release and the TBB tests need be extended.Thank you very much
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jimdempseyatthecove wrote:The task_scheduler_init object is explicitly deleted, but only when unloading the COM DLL. No TBB operations are being performed at this point, and all objects that were created using the DLL should have been released. IOW the COM DLL is only released when the program is closed, and only then. Regards, Paúl.Are you explicitly deleting the task_scheduler_init object (prior to termination/exit of all tasks)?
IOW you have some (exception) condition (or convergence) and you wish to stop execution and chose to do so via "delete" on the task_scheduler_init objectJim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
binksoftware wrote:Hi.
Quote:
Wooyoung Kim (Intel) wrote:I tried to reproudce the hang you mentioned here by compiling the TBB tests with 4.1 headers and running them with 4.0U5 DLL.
Unfortunately, I was not able to reproduce any hang. Could you give us a bit more information regarding the nature of your application?
In particular, we would like to know what TBB constructs the application uses. That will help us understand the cause of the problem: whether the problem is due to the API changes from 4.0U5 to 4.1 or it is due to a bug in the TBB release and the TBB tests need be extended.Thank you very much
The program uses tbb::atomic (mostly for reference counting), tbb::spin_mutex for (occasional) locking and the parallel_for and parallel_do template functions. The program also uses the scalable_malloc and scalable_free functions for memory allocation of objects and containers. I don't recall using anything else.
Regards,
Paúl.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wooyoung Kim (Intel) wrote:The reproducer I provided in Premier Support is the only reproducer I have (which happens to be the full application). That one was compiled with TBB 4.1, and by just replacing the DLL with that of TBB 4.0U5 I had the early hang. I don't really think swapping DLLs is the way to go, though. Regards, Paúl.Thanks a lot!!
Does your reproducer show this kind of issues, too? I.e., if I run it with 4.0U5 DLL, does it hang in the middle of execution?
I have looked at the changes log and the diffs for those TBB constructrs between 4.0U5 and 4.1, but it does not seem obvious
what changes might have caused the issue. If your previous reproducer does not have the issue, would you mind giving us another small reproducer?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In case someone else is interested, Intel reverted the code that introduced the issue. It is available in TBB 4.1 Update 1. It's not part of the release notes, though.
Thanks again for the fix.
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page