Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

strdup() and tbbmalloc_proxy

e4lam
Beginner
110 Views
It appears that tbbmalloc_proxy doesn't provide stubs for strdup(), resulting in generated exceptions at run time when free() is called for strdup'ed memory. Should I be concerned? Can we add a strdup() to tbbmalloc_proxy?

Thanks!
0 Kudos
1 Solution
Vladimir_P_Intel2
110 Views
hi, this is expected behavior on some of debug configurations since we not replace _malloc_dbg(). there is some slowdown in debug config but it is not relevant since it is debug. Release configuration should work just fine and throw exception only in case you allocate memory in constructor of static object before tbbmalloc_proxy is loaded.

thanks
--Vladimir

View solution in original post

6 Replies
Vladimir_P_Intel2
110 Views
hi e4lam,

strdup() calls malloc() usually. So it should work with 2.2 u3. Which architecture, OS version and compiler do you use?

thanks.
--Vladimir
e4lam
Beginner
110 Views
I am using tbb 2.2 u3 *debug* on Windows 64-bit, Visual Studio 2005. The reason why I brought it up is because I actually see these (first-chance) exceptions being generated and when I step into strdup(), it calls malloc_dbg() and into the internal CRT function _heap_alloc_dbg as opposed going into TBB. On the other hand, if I step into malloc() or free() calls, it goes into TBB.

-Edward
Vladimir_P_Intel2
110 Views

Ah, there is no crash, only exception occurs which is caught and rtl version of free() is called, right?

--Vladimir

e4lam
Beginner
110 Views
Yes, sorry for not being clear. This seems to indicate that at least on debug builds, strdup() ends up calling the malloc() instead of TBB's scalable_malloc(). I don't have a release build at the moment but I'm guessing that this is probably the case on release builds as well? If so, then this is a potential performance problem when using tbbmalloc_proxy.
Vladimir_P_Intel2
111 Views
hi, this is expected behavior on some of debug configurations since we not replace _malloc_dbg(). there is some slowdown in debug config but it is not relevant since it is debug. Release configuration should work just fine and throw exception only in case you allocate memory in constructor of static object before tbbmalloc_proxy is loaded.

thanks
--Vladimir

View solution in original post

e4lam
Beginner
110 Views
Thanks, Vladimir! Sorry for jumping the gun there with the debug build. I took a while for me to get my release build up and running again to confirm the release build behaviour myself.
Reply