diff options
author | Mike Hommey <mh@glandium.org> | 2017-01-17 07:20:05 (GMT) |
---|---|---|
committer | Jason Evans <jasone@canonware.com> | 2017-01-18 04:13:28 (GMT) |
commit | 12ab4383e9ea743e8e6b9115be73f2c6dfde5e24 (patch) | |
tree | e1578ba598815ac39e453b141092831480a398d7 /src/ctl.c | |
parent | 0f7376eb6295fcd751956cb3df248e838eea003f (diff) | |
download | jemalloc-12ab4383e9ea743e8e6b9115be73f2c6dfde5e24.zip jemalloc-12ab4383e9ea743e8e6b9115be73f2c6dfde5e24.tar.gz jemalloc-12ab4383e9ea743e8e6b9115be73f2c6dfde5e24.tar.bz2 |
Add dummy implementations for most remaining OSX zone allocator functions
Some system libraries are using malloc_default_zone() and then using
some of the malloc_zone_* API. Under normal conditions, those functions
check the malloc_zone_t/malloc_introspection_t struct for the values
that are allowed to be NULL, so that a NULL deref doesn't happen.
As of OSX 10.12, malloc_default_zone() doesn't return the actual default
zone anymore, but returns a fake, wrapper zone. The wrapper zone defines
all the possible functions in the malloc_zone_t/malloc_introspection_t
struct (almost), and calls the function from the registered default zone
(jemalloc in our case) on its own. Without checking whether the pointers
are NULL.
This means that a system library that calls e.g.
malloc_zone_batch_malloc(malloc_default_zone(), ...) ends up trying to
call jemalloc_zone.batch_malloc, which is NULL, and crash follows.
So as of OSX 10.12, the default zone is required to have all the
functions available (really, the same as the wrapper zone), even if they
do nothing.
This is arguably a bug in libsystem_malloc in OSX 10.12, but jemalloc
still needs to work in that case.
Diffstat (limited to 'src/ctl.c')
0 files changed, 0 insertions, 0 deletions