Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
35 Views

strdup() and tbbmalloc_proxy

Jump to solution
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

Accepted Solutions
Highlighted
35 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

0 Kudos
6 Replies
Highlighted
35 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
0 Kudos
Highlighted
Beginner
35 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
0 Kudos
Highlighted
35 Views

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

--Vladimir

0 Kudos
Highlighted
Beginner
35 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.
0 Kudos
Highlighted
36 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

0 Kudos
Highlighted
Beginner
35 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.
0 Kudos