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

[Mark_W_]

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.

[Alexei_K_Intel]

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_]

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]

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_]

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_]

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]

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