Bug 16939

Summary:	revert malloc hook deprecation or provide an alternative
Product:	glibc	Reporter:	Daniel Micay <danielmicay>
Component:	malloc	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	adhemerval.zanella, yann
Priority:	P2	Flags:	fweimer: security-
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

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.