diff options
author | Adrian Kummerlaender | 2016-02-17 15:02:48 +0100 |
---|---|---|
committer | Adrian Kummerlaender | 2016-02-17 15:02:48 +0100 |
commit | af756d78ac042a2eed2417c5250d4b675d43bf93 (patch) | |
tree | aedc585d49a5d7eb5549e81c78db43f08dedc9a3 /src/actual.h | |
parent | 98f68dd9bb0318acfaaf7f2e7ad571a19729a8bb (diff) | |
download | change-af756d78ac042a2eed2417c5250d4b675d43bf93.tar change-af756d78ac042a2eed2417c5250d4b675d43bf93.tar.gz change-af756d78ac042a2eed2417c5250d4b675d43bf93.tar.bz2 change-af756d78ac042a2eed2417c5250d4b675d43bf93.tar.lz change-af756d78ac042a2eed2417c5250d4b675d43bf93.tar.xz change-af756d78ac042a2eed2417c5250d4b675d43bf93.tar.zst change-af756d78ac042a2eed2417c5250d4b675d43bf93.zip |
Implement static allocator for initialization
The previous interposition logic based on plain usage of `dlsym` analogously to various online examples led to a deadlock during _neovim_ startup. This deadlock was caused by _neovim_'s custom memory allocation library _jemalloc_ because it calls `mmap` during its initialization phase. The problem with calling `mmap` during initialization is that this already leads to executing `libChangeLog`'s `mmap` version whoes static `actual_mmap` function pointer is not initialized at this point in time. This is detected and leads to a call to `dlsym` to remedy this situation. Sadly `dlsym` in turn requires memory allocation using `calloc` which leads us back to initializing _jemalloc_ and as such to a deadlock.
I first saw this as a bug in _jemalloc_ which seemed to be confirmed by a short search in my search engine of choice. This prompted me to create an appropriate [bug report](https://github.com/jemalloc/jemalloc/issues/329) which was dismissed as a problem in the way `mmap` was interposed and not as a bug in the library. Thus it seems to be accepted practice that it is not the responsibility of a custom memory allocator to cater to the initialization needs of other libraries relying on function interposition. This is of course a valid position as the whole issue is a kind of _chicken and egg_ problem where both sides can be argued.
To cut to the chase I was left with the only option of working around this deadlock by adapting `libChangeLog` to call `dlsym` without relying on the wrapped application's memory allocator of choice. The most straight forward way to do this is to provide another custom memory allocator alongside the _payload_ function interpositions of `mmap` and friends.
`init/alloc.cc` implements such a selectively transparent memory allocator that offers a small static buffer for usage in the context of executing `dlsym`.The choice between forwarding memory allocation requests to the wrapped application's allocator and using the static buffer is governed by `init::dlsymContext`. This tiny helper class maintains an `dlsym_level` counter by posing as a scope guard.
The end result of this extension to `libChangeLog` is that it now also works with applications using _jemalloc_ such as _neovim_ and should overall be much more robust during its initialization phase.
Diffstat (limited to 'src/actual.h')
-rw-r--r-- | src/actual.h | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/src/actual.h b/src/actual.h index cb08d42..a860590 100644 --- a/src/actual.h +++ b/src/actual.h @@ -1,10 +1,10 @@ +#ifndef CHANGE_SRC_ACTUAL_FUNCTION_H_ +#define CHANGE_SRC_ACTUAL_FUNCTION_H_ + #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif -#ifndef CHANGE_SRC_ACTUAL_FUNCTION_H_ -#define CHANGE_SRC_ACTUAL_FUNCTION_H_ - #include <dlfcn.h> #include <sys/mman.h> #include <sys/uio.h> @@ -12,6 +12,8 @@ #include <memory> #include <cstring> +#include "init/alloc.h" + namespace actual { template <class Result, typename... Arguments> @@ -19,6 +21,8 @@ using ptr = Result(*)(Arguments...); template <typename FunctionPtr> FunctionPtr get_ptr(const std::string& symbol_name) { + init::dlsymContext guard; + const void* symbol_address{ dlsym(RTLD_NEXT, symbol_name.c_str()) }; FunctionPtr actual_function{}; |