Bug 16939 - revert malloc hook deprecation or provide an alternative
Summary: revert malloc hook deprecation or provide an alternative
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: malloc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-13 07:45 UTC by Daniel Micay
Modified: 2017-01-30 10:36 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Micay 2014-05-13 07:45:33 UTC
This feature was deprecated because these hooks aren't usable as a thread-safe wrapper around the glibc allocator, but they are certainly usable in a thread safe manner with another allocator where you don't need to save and restore the hooks before calling the allocator.

The weak symbols aren't a robust way of doing this because they don't work with static linking, where it will simply cause symbol conflicts. If the deprecation isn't going to be undone, an alternative should be provided for this use case.

It's important to provide a way of reliably replacing the glibc allocator with jemalloc, tcmalloc, Hoard or another general purpose allocator. The glibc allocator may eventually be improved to the point where it's competitive with jemalloc/tcmalloc for general purpose single/multi-threaded workloads, but there will still be a use case for allocators targeted at different niches.

We're using jemalloc in Rust by statically linking it into the standard library and explicitly calling it via the non-standard API, but replacing the glibc allocator is desirable due to eliminate the external fragmentation caused by using 2 memory allocators in one process.

Statically linking against the standard C library is questionable, but it's not really a programming language's place to tell you not to do it, so we need to use the hooks rather than the weak symbols.

Here's an old post about this by the author of Hoard:

https://sourceware.org/ml/libc-alpha/2011-07/msg00136.html
Comment 1 Daniel Micay 2014-05-13 21:56:16 UTC
Here's the hook usage in jemalloc with an explanation of why this is required even in dynamically linked binaries:

https://github.com/jemalloc/jemalloc/blob/dev/src/jemalloc.c#L1339
Comment 2 Adhemerval Zanella 2017-01-30 10:36:31 UTC
For 2.25 GLIBC has fixed some issues (BZ#17730, BZ#20432, BZ#20432) to support and simplify both dynamic and malloc interposition. There is no need to known glibc internal symbols neither interpose them to actually interpose the malloc on both glibc and loader (check malloc/tst-interpose-* tests).

It is, however, non compatible solutions and some old releases do not support these fixes (I have backported them to my own branchs, linaro/2.21/master and linaro/2.23/master, so you might check what is required to interpose them). 

We can backport them to old releases branches so static allocation is correctly supported, however malloc hooks will not be reverted since they are, as you correctly pointed out, a deficient API with many issues and current approach solves these issues.