Showing results for 
Search instead for 
Did you mean: 

[SOLVED] TBB and floating point exceptions


I'm having some trouble using floating point exceptions (FPE) with TBB in release mode. Basically when an FPE happens I want my program to show the windows crash dialog with the option to attach a debugger.  This works fine for programs compiled in debug mode for FPE both inside and outside TBB algorithms. For release mode builds FPE outside TBB algorithms also produce the desired crash, but for FPE inside TBB the error is translated into a C++ exception, which seems inconsistent.


debug mode + outside parallel_for: crash dialog

debug mode + inside parallel_for: crash dialog

release mode + outside parallel_for: crash dialog

release mode + inside parallel_for: unknown exception thrown!

How do I avoid TBB translating my FPE to a C++ exception?

Kind regards



extern float bar = -1.f;

int main(int argc, char* argv[])



tbb::task_scheduler_init tsi;

std::vector<float> foo(16);

//make FPE outside TBB

//foo[0] = std::sqrt(bar);

try {
tbb::blocked_range<size_t>(0, foo.size()),
[&](const tbb::blocked_range<size_t>& range) {

for (auto i=range.begin(); i!=range.end(); ++i)
std::printf("%i\n", int(i));
foo = std::sqrt(float(i));

//make FPE inside TBB algorithm

if (i==15)
foo = std::sqrt(bar);
}, tbb::auto_partitioner());

}catch (std::exception& e)
std::printf("exception: %s\n", e.what());

return 0;



0 Kudos
4 Replies
Black Belt

Is this for a Microsoft compiler on x86? Then aren't those settings only for SSE instructions, with FPU instructions still masked by default? But even if the compiler decides on SSE by default and only uses the FPU to optimise that particular case, it shouldn't generate a C++ exception, I suppose.

I've experienced that this environment will catch(...) a bus error (when dereferencing a dangling pointer or so), which is also rather strange (compared to Linux). What happens if you surround the freestanding offending instruction with a try/catch(...)? If it is caught that way, perhaps that might hint at an explanation after inspecting the source code for TBB, but it's a long shot, and others with more FP experience in this environment (or access to it for reproduction purposes) might be better able to assist.

BTW, you don't need a task_scheduler_init anymore (except for specific purposes).


Thanks for replying.  I'm using vs2012 and 64bit mode, so no FPU.

I figured out the cause..  When I ran the program from inside VS (both with and without debugging) my program used the correct tbb.dll from the distribution of tbb that I was linking against.  But when I ran from command prompt it used whatever tbb.dll it found in the path, which happened to be and old version of tbb.  This is what was causing the exception in release mode.

Black Belt

Thanks for letting us know (I'll assume you only just found out, yourself).



Could you put [SOLVED] to the subject that people can google the answer later?