Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Mark_W_
Beginner
45 Views

What is : Unexpected exception or cancellation data in the masters dummy task

When I get this message as part of an assert / abort ...

"Unexpected exception or cancellation data in the masters dummy task"

What is a likely cause ?  What tricks might I used to try to diagnose this further and maybe find the 

root cause ? 

It sounds like a master task has been unreasonable about allowing a task to finish gracefully,

but that's just a guess on my part.

Any hints or elaborations or guesses would be appreciated.

0 Kudos
6 Replies
Alexei_K_Intel
Employee
45 Views

Hi Mark,

This message means that a task with a default task_group_context threw an exception. Do you use Intel TBB Task API directly? Or do you use task::enqueue or task_arena::enqueue functions?

Regards,
Alex

Mark_W_
Beginner
45 Views

We use some of both AFAIK.  I'm new to the codebase and also new to all things TBB.

We use  ::run   ::enqueue  ::parallel_for   

We use a lot of ::parallel_for

We don't seem to use any  task_arena::enqueue  or any task_arena:: for that matter.

Alexei_K_Intel
Employee
45 Views

To enqueue a task you need to create this task explicitly, e.g. new (task::allocate_root()) MyTask(). How do you allocate the tasks that are enqueued?

Mark_W_
Beginner
45 Views

Just in case there is something interesting here that I didn't share before ... this is the full test that happens during the  error/assert 

 

x64\Debug\tbb_debug.dll
Module: tbb_debug.dll
File: c:\temp\tbbtesting\tbb.2016_10_04t22_53_01__03_00.83f7e5a5ef67.nntpat52-38\1.0\src\tbb\custom_scheduler.h
Line: 689

Expression: !master_outermost_level() || !CancellationInfoPresent(*my_dummy_task)
Unexpected exception or cancellation data in the master's dummy task

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

Mark_W_
Beginner
45 Views

OK ...  after reading the assert message carefully ...

I decided to try making the  parent thread  use a  TBB  task scheduler and task group  ... rather than another Boost threadpool.

My idea was harmony of approach, consistency.   So originally a Boost thread pool was used to spawn workers from a thread-safe API. This was not under my control at first and was given to me as sample code to debug.  When I changed to TBB ...  it did seem that all was better after man trials and tests. 

Did I just make a bug happen less often ?  Or maybe I solved the problem ?  I guess time will tell.

Alexei_K_Intel
Employee
45 Views

Hi Mark,

Intel TBB runtime implements so-called exception propagation mechanism. It is the mechanism that guarantees that an exception thrown on Intel TBB worker thread will be re-thrown on the thread that calls Intel TBB algorithm. However, to benefit from this mechanism you need to use task_group_context. Many Intel TBB parallel algorithms use task_group_context and guarantee that the exception will be handle properly and can be caught in the user code.

The assert states that a task has thrown an exception but it has not been bound to an user-provided task_group_context, so it has been caught into the default task_group_context. It is dangerous because the default context is not available for the user and the exception will be missed. So Intel TBB runtime asserts about this problem.

Usually, this problem can be faced if Intel TBB Task API is used directly, e.g. task::enqueue (because the task can be allocated with default context). Could you check how tasks are allocated and check if  the code can throw the exception?

Regards,
Alex