diff options
Diffstat (limited to 'source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md')
| -rw-r--r-- | source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md | 11 |
1 files changed, 0 insertions, 11 deletions
diff --git a/source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md b/source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md deleted file mode 100644 index 8c81150..0000000 --- a/source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. |