Date: Tue, 10 Apr 2018 22:33:55 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Cc: Rich Felker <dalias@...c.org>, Florian Weimer <fw@...eb.enyo.de> Subject: Re: tcmalloc compatibility * Florian Weimer <fw@...eb.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.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ