strdup() and tbbmalloc_proxy

[e4lam]

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!

[Vladimir_P_1234567890]

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]

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

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

--Vladimir

[e4lam]

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_1234567890 · Accepted solution]

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

[e4lam]

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.