aboutsummaryrefslogtreecommitdiff
path: root/src/filter
diff options
context:
space:
mode:
authorAdrian Kummerlaender2016-02-17 15:02:48 +0100
committerAdrian Kummerlaender2016-02-17 15:02:48 +0100
commitaf756d78ac042a2eed2417c5250d4b675d43bf93 (patch)
treeaedc585d49a5d7eb5549e81c78db43f08dedc9a3 /src/filter
parent98f68dd9bb0318acfaaf7f2e7ad571a19729a8bb (diff)
downloadchange-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/filter')
0 files changed, 0 insertions, 0 deletions