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

Problem with MALLOC_ASSERT in RegisterProcessShutdownNotification on Mac

We just updated our TBB libraries from 4.0 (tbb40_20110809oss) to 4.0 update 5 (tbb40_20120613oss). The addition of the MALLOC_ASSERT in RegisterProcessShutdownNotification (tbbmalloc.cpp line 166) is causing us problems on Mac.

At some point the code was changed from this:
[cpp] RegisterProcessShutdownNotification() { #if USE_PTHREAD && __TBB_DYNAMIC_LOAD_ENABLED // prevents unloading, POSIX case dlopen(MALLOCLIB_NAME, RTLD_NOW); #endif } [/cpp]
to this:
[cpp] RegisterProcessShutdownNotification() { // prevents unloading, POSIX case void *ret = dlopen(MALLOCLIB_NAME, RTLD_NOW); MALLOC_ASSERT(ret, "Allocator can't load ifself."); } [/cpp] The original 4.0 code was ignoring the return code from dlopen. The new code asserts if the dlopen call fails. Unfortunately, the use of dlopen is problematic on Mac. It requires that either the tbb libraries are installed into /usr/local/lib or /usr/lib, or that the path to the tbb libraries is specified in the DYLD_LIBRARY_PATH environment variable. Both of these options are non-starters for our installation in which the tbb libraries are embedded as private shared libraries in our app bundle.
I'm guessing that when we were using the old 4.0 code, the call to dlopen was failing silently. This does not appear to have been causing any problems for our application running on Mac, presumably because of the way the OS X dynamic loader works.
So, two questions:
1) Are there any known issues where the tbbmalloc library gets unloaded prematurely on Mac (which is presumably the situation the call to dlopen is trying to prevent)?
2) If this is an issue on Mac, is there a way to fix it without requiring changes to the user's global environment? If not, can the code be modified for Mac to bypass the call to dlopen?
0 Kudos
1 Reply
hello Rob,

Thanks for the report. We decided to remove thisMALLOC_ASSERT until further evaluation of different scenarious like -rpath, etc.
the changed library will be available in next update.
Answering to your questions:
1) If tbbmalloc unloaded before application ends the first call to memory release that was allocated by tbbmalloc will crash the application. Manual unload of tbbmalloc is not a common usage scenario so in general case this dlopen fail application will work without any problems.
2) The problem is the same on both linux and mac.
0 Kudos