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

tbbmalloc_proxy and shared libraries (Windows)

e4lam
Beginner
862 Views

Hi Folks,

I have 2 applications which use the same shared libraries and I only want one of them to use tbbmalloc_proxy. Is there a good way to do this on Windows?

Currently, all of my applications are using tbbmalloc_proxy because tbbmalloc_proxy.h is carefully included a library that everyone else links against so that static constructors in each of the DLL's will use tbbmalloc for memory allocation. However, I want to allow third-parties to link against these libraries where I shouldn't be forcing tbbmalloc_proxy on them. In fact, if the static construction order is wrong, we can have the third party constructors allocate memory using CRT malloc() and then deallocating it using tbbmalloc (which seems to cause crashes).

Thanks!

0 Kudos
4 Replies
Vladimir_P_1234567890
862 Views

Hello,

the scenario where "third party static constructors allocate memory using CRT malloc() and then deallocating it using tbbmalloc" should be supported. Do you experience a crash in this case? tbbmalloc should call original CRT free/delete in case it sees that the memory was not allocated by tbbmalloc.

Actually there is no "correct order" of calling of static constructors:)

--Vladimir

0 Kudos
e4lam
Beginner
862 Views

You're right, the crash (after communications with our client) now points to the tbbmalloc problems in the thread I just started: http://software.intel.com/en-us/forums/topic/494621

However, I still need some way to avoid doing tbbmalloc_proxy hooks since it's not expected behaviour to override the system allocator for third-party applications.

0 Kudos
Vladimir_P_1234567890
862 Views

ok I see.

replacement is application-wide

If you use different versions of C runtime in your and 3rd party code (i.e. VS2010 and VS2013) you can delete non-relevant to your code lines in the "modules_to_replace​" array in the proxy.cpp file and rebuild the proxy library.

--Vladimir

0 Kudos
e4lam
Beginner
862 Views

As a more flexible mechanism, it might be a good idea to allow some environment variable to control the hooking behaviour. In tbbmalloc/proxy.cpp, we currently have a special (disabled) code path for TBBMALLOC_USE_TBB_FOR_ALLOCATOR_ENV_CONTROLLED that disables hooking unless TBBMALLOC_USE_TBB_FOR_ALLOCATOR is set. Perhaps, we can change it to something more flexible (and enabled by default) like this:

        char *pinEnvVariable[50];
        bool found = (GetEnvironmentVariable("TBBMALLOC_USE_TBB_FOR_ALLOCATOR", pinEnvVariable, 50) > 0);
        if (!found || strcmp(pinEnvVariable, "0") != 0) {
            doMallocReplacement();
        }

I'm not sure what the policy is on environment variables for TBB though.

Ultimately, I've changed our use on this to only link in tbbmalloc_proxy when building the final application as opposed to the linking of each individual shared library. This does mean that third party applications will need to do more work if they want tbbmalloc_proxy.

On a side note, has anyone looked into add tbbmalloc_proxy support on OSX?

0 Kudos
Reply