Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

exception handling and coredumps

MLema2
New Contributor I
253 Views
Hi, I was wondering if there is a good way to catch exceptions and generate a coredump from within TBB threads.. We need to be able to have corecump at the exact point of the exception when something critical occurs within a parallel algorithm.

Currently, I set an SEH translator with task_scheduler_observer:

class SEHHandler : public tbb::task_scheduler_observer
{
public:
SEHHandler() {
observe(true);
}
void on_scheduler_entry(bool is_worker) {
if (is_worker) {
_set_se_translator(MySEHTranslator);
}
}
} g_SEHHandler;

That said, if an exception (C++ or SEH) occurs in a TBB thread, it get caught and rethrown in the main calling thread without any context.

The only way I could find to make it work under windows/msvc was to put a try/except block in custom_scheduler.h in method:void custom_scheduler::local_wait_for_all()

__try {
...
} __except(MyExceptionHandler(GetExceptionInformation())) {
}
and

LONG MyExceptionHandler(EXCEPTION_POINTERS*)
{
... call my routine to coredump process ...
return EXCEPTION_CONTINUE_SEARCH;
}
Any other ideas?
Mike
0 Kudos
3 Replies
Anton_M_Intel
Employee
253 Views
Hi, I have some ideas to play with..
TBB has C++ exception handling support, please read the Reference: "Exceptions". And custom_scheduler already has catch blocks, please seeTbbCatchAll.
For SEH, you could use SEH translator to generate a dereviative from tbb::movable_exception and put your coredump code intomove() method. Though,I'm not sure whetherexact point of the exception can berestored this way (through C++ catch).
For C++ exception which cannot be derived from movable_exception, we have no other way to intercept it in original thread beside obvious ones:
1) put try-catch into body of your parallel algorithms
2)completely disable exception support by re-compiling TBB withTBB_USE_EXCEPTIONS=0.
In the latter case, an unhandled exception will cause the termination of the process which can be intercepted via a handler set by set_terminate().
Please say whether the suggested ideas are sufficient for you. And if not, please desribe your use-case in details so we could consider whether to support it, e.g. by extending observer with (for example) on_exception() callback..
0 Kudos
MLema2
New Contributor I
253 Views
Hi, thanks for your answers..
First option might not be ideal since it pollute every call site..
I tried second option and found that under the debugger, there is a default handler set that catches exceptions and display a messge box.. It won't enter function given to set_terminate. Outside the debugger, it works fine.
Not sure yet which one best fits our needs..
Regards.
0 Kudos
MLema2
New Contributor I
253 Views
Although, an on_exception() would be nice too ;)
0 Kudos
Reply