exit() calls in TBB

[e4lam]

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!

[RafSchietekat]

Just install an exit handler that calls abort()?

[e4lam]

> Just install an exit handler that calls abort()?

Er, I don't know where to begin on how obviously wrong that would be.

[RafSchietekat]

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]

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]

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

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]

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