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

exit() calls in TBB

e4lam
Beginner
92 Views
It would help immensely if the exit() calls in TBB, at least the ones in tbbmalloc/frontend.cpp, were replaced with abort().

We just ran into a crash that is only reproduceable on the client end where it exits with "The memory manager cannot access sufficient memory to initialize; exiting". Normally, such crashes would produce a crash report that the client could send us because we have signal handlers to catch them. However, these exit() calls are preventing us from being able to properly debug the problem.

Thanks!
0 Kudos
7 Replies
RafSchietekat
Black Belt
92 Views
Just install an exit handler that calls abort()?
e4lam
Beginner
92 Views
> Just install an exit handler that calls abort()?

Er, I don't know where to begin on how obviously wrong that would be.
RafSchietekat
Black Belt
92 Views
Would it not help you find the cause of the current problem? Of course, if the problem is not highly reproducible and you want to deploy it in the field, you would have to be able to disable it before a normal exit of course, which may easily disqualify it.

Or you could wait for a discussion on whether abort() would be entirely appropriate, and then wait some more until a new version comes out (I assume that you need an official version, otherwise you could just modify the source code yourself)...
e4lam
Beginner
92 Views
To find the current problem, I've already patched our own build of TBB with the abort() calls.

The point of this discussion is that calling exit() in the event of an error in a general library is a bad thing to begin with. I haven't looked closely at when those functions get called. Perhaps throwing an exception might be more appropriate. The point is that I don't want to maintain my own patch on top of TBB indefinitely.
RafSchietekat
Black Belt
92 Views
So what was the current problem? Did the rest of the program already exhaust memory in a pathological turn of events, before TBB first entered the picture? Were you able to solve it?

For a long-term improvement, it would seem best to follow established conventions and merely return NULL, unless malloc() also does something else if it somehow cannot initialise itself. Throwing an exception already assumes C++, and the scalable allocator has a C interface. It's the responsibility of whatever ties it to new/delete to translate this into throwing bad_alloc.
Alexey_K_Intel3
Employee
92 Views
Thanks for bringing up the issue. We discussed it in the team and decided that it should be addressed; the exact solution is yet to be defined, with the main question to us being how to give application developers some programmatic control over the behavior.
jimdempseyatthecove
Black Belt
92 Views
Alexey,

Perhaps TBB could have a global functor, which the user can replace, that points to

void TBB_abend()
{
exit();
)

The user could then change the functor to something of their own design.

Args could be passed to the abend routine.

This is not unlike inserting your own new handler.

Note, when an internal error occures, the TBB thread scheduler is most likely bunged-up and the app is imminant of crashing. But, this may provide for a graceful way of crashing (and the app might be able to resume itself).

As to if this can be worked into the exception handling, I cannot say.

Jim Dempsey
Reply