Help regarding bug 25533 (RTLD_DEEPBIND, glibc, custom memory manager)

[rajpal gusain <rajpal.gusain@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

Hi all,
I need help regarding an issue for which I created bug 25533 a while ago.

The issue is mainly because of complex interaction of RTLD_DEEPBIND, libc and custom memory manager. 
Let me explain issue first
1. In my application, I use a third party application which makes use of dlopen with RTLD_DEEPBIND flag
2. In my application, this third party application is linked statically along with Google’s memory manager (gperftools <https://github.com/gperftools/gperftools>).
3. When third party application calls dlopen with RTLD_DEEPBIND flag, strdup (along with malloc) gets picked from glibc. 
4. free definition is still communing from custom memory manager and it’s a problem as malloc’ed memory was allocated by libc malloc while free call is directed to custom memory manager.

I asked third party application vendor to fix it at their end (dlopen with RTLD_DEEPBIND), but they expressed their inability to do it as it has side effect.
I filed ticket against tcmalloc as well but it also hit dead end. As a workaround, I made use of malloc hooks.

But, I consider malloc hooks as temporary workaround and I’m looking for proper solution to this problem and IMO, proper fix should be in glibc which should be agnostic to memory manager 
that any application chooses. I believe jemalloc (Facebook) also has same issue and they also have used malloc hooks to work around this problem. 
Through this email, I’m looking for suggestions to fix this issue properly. 

I have created a small test case which is not exactly what is there in my application but closely resembles what I see. It’s dependent on TCMALLOC_STATIC_LIB variable which should be path to static library (.a) for custom memory manager.



Thanks
Rajpal Singh

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1394 bytes --]