Re: tcmalloc compatibility

[Szabolcs Nagy <nsz@port70.net>]

* Florian Weimer <fw@deneb.enyo.de> [2018-04-10 19:53:46 +0200]:
> We have some documentation nowadays:
> 
> <https://www.gnu.org/software/libc/manual/html_node/Replacing-malloc.html>
> 
> The remaining undocumented aspects concern cyclic dependencies, such
> as the suitability of certain TLS models for implementing a custom
> malloc, or using memory-allocating glibc functions such as fopen or
> backtrace from the allocator itself.
> 

it's not documented what the interposed malloc may or may not do.

cyclic dependency (because malloc calls a memory-allocating libc
function) is one issue, but in general the libc can be in an
inconsistent state at the point of an internal malloc call (e.g.
some lock is held that should never be held when user code is
running) and thus certain other libc functions may not operate
as expected in an interposer.

documenting the set of libc apis that work as expected in an
interposer is difficult.

> In practice, malloc interposition works extremely well and causes few
> issues due to interposition itself.  Obviously, there are bugs, but
> most of them would still be bugs if the allocator was non-interposing.
> (Examples are lots of initial-exec TLS data, and incorrect alignment
> for allocations.)
> 

even with the very small set of libc apis that a malloc
interposer may want to use, there known (but undocumented)
caveats:

- glibc dlsym calls calloc (bites anybody who tries to wrap
calloc in the usual way)

- general dynamic tls may call malloc and uses global dl
lock so using tls can cause recursion or deadlock.

- using stdio for logging is problematic because of stdio
locks and recursive malloc calls.

- malloc may get called before the first ctor and after
the last dtor.

- malloc may be called on a thread with small stack
(e.g. gai helper thread) so it should not have excessive
stack usage.

- glibc fork tries to reset the malloc state before
calling the child atfork handler in an attempt to support
non-as-safe fork handlers, code that relies on this can
get broken with malloc interposition.

interposition only seems to work extremely well because
users already fixed their code and things dont change
much in this space.

> I believe musl uses less malloc internally, so it should be even more
> compatible with an interposing malloc implementation than glibc.