[Bug nptl/24776] pthread_key_create, pthread_setspecific are incompatible with dlmopen

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24776

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #3)
> We probably cannot use malloc for allocating the internal data structures. 
> If we keep using it, we need to call through a wrapper function in GLRO (or
> ld.so in general), to reach into the right namespace.

My opinion is that we may be able to take a hybrid approach to the problem.

I believe that for certain parts of rtld we can and should use an internal
allocator that is isolated from all the allocators in the namespaces. For the
purpose of consistency and accountability this allocator cannot be interposed.
These allocations are almost always related to book-keeping tasks.

For other parts of rtld where rtld acts on *behalf* of another API request, it
seems logical to try and use the allocator from the namespace, tag the
allocation with namespace information, and then release it back using the same
namespace.

Back to the question at hand. If the user supplied destructor calls malloc/free
then as long as we run it in the original namespace the objects will be
correctly  allocated and released in the right place. If the user supplied
destructor calls a shared-rtld function (directly or indirectly) which returns
a pointer that the destructor must free, then the underlying shared-rtld
functions must be of the kind I describe above as "acts on *behalf* of another
API" and so must also come from the enclosing namespace.

One way to solve this is:
* Consider the space used by pthread_setspecific to be an "implementation
detail" and use a new rtld_calloc() function to allocate it from rtld.
* Subsequent frees in __nptl_deallocate_tsd use rtld_free().

So we invert the problem and move the allocations to the shared rtld namespace,
rather than recording where they came from to free them correctly (possibly
costly).

-- 
You are receiving this mail because:
You are on the CC list for the bug.