-
Jusufadis Bakamovic authored
Problem: - ASAN reports memory-leak on TempTable operation - e.g. CREATE DATABASE test; USE test; SHUTDOWN; Analysis: - TempTable allocator keeps the last block of memory alive until the thread-exit. It does so by putting this block into the thread-local-storage. - Reason for a memory-leak is twofold: 1. Routine (destructor) responsible for deallocation of this last block of memory is not even invoked. 2. Code-path in this routine which should do the actual deallocation does not get hit when compiled with GCC and optimizations turned on. Clang & MSVC are fine with it. Solution: 1. C++14 standard (http://eel.is/c++draft/basic.stc#thread ) says that namespace-scoped variables are lazily-initialized and it is very much possible that they don't get constructed at all if compiler doesn't see them being referenced anywhere in the code. Similar applies to block-scoped (e.g. function-local) thread-locals whose construction will not take place if execution path never hits them. Fix: just force the so called first-odr-use of a namespace-scoped thread-local (our last block). 2. This one is much more subtle and due to the inconsistency in behavior observed when using different compilers, as of now it is considered as an erroneous behavior (bug) in one of the them (presumably GCC). Fix: create code which works consistently across all compilers and carefully re-implement unit-tests which will make sure that this memory-leak is fixed. E.g. replacing raw-uint8_t-ptr block representation with glorified-uint8_t-ptr representation (e.g. ptr wrapped into a struct) does the job. Future work, which requires more investigation, may include removal of caching the last-block mechanism and hence getting rid of necessity for thread-local-storage completely. Reviewed-by:
Pawel Olchawa <pawel.olchawa@oracle.com> Reviewed-by:
Marcin Babij <marcin.babij@oracle.com> Reviewed-by:
Tor Didriksen <tor.didriksen@oracle.com>
Jusufadis Bakamovic authoredProblem: - ASAN reports memory-leak on TempTable operation - e.g. CREATE DATABASE test; USE test; SHUTDOWN; Analysis: - TempTable allocator keeps the last block of memory alive until the thread-exit. It does so by putting this block into the thread-local-storage. - Reason for a memory-leak is twofold: 1. Routine (destructor) responsible for deallocation of this last block of memory is not even invoked. 2. Code-path in this routine which should do the actual deallocation does not get hit when compiled with GCC and optimizations turned on. Clang & MSVC are fine with it. Solution: 1. C++14 standard (http://eel.is/c++draft/basic.stc#thread ) says that namespace-scoped variables are lazily-initialized and it is very much possible that they don't get constructed at all if compiler doesn't see them being referenced anywhere in the code. Similar applies to block-scoped (e.g. function-local) thread-locals whose construction will not take place if execution path never hits them. Fix: just force the so called first-odr-use of a namespace-scoped thread-local (our last block). 2. This one is much more subtle and due to the inconsistency in behavior observed when using different compilers, as of now it is considered as an erroneous behavior (bug) in one of the them (presumably GCC). Fix: create code which works consistently across all compilers and carefully re-implement unit-tests which will make sure that this memory-leak is fixed. E.g. replacing raw-uint8_t-ptr block representation with glorified-uint8_t-ptr representation (e.g. ptr wrapped into a struct) does the job. Future work, which requires more investigation, may include removal of caching the last-block mechanism and hence getting rid of necessity for thread-local-storage completely. Reviewed-by:
Pawel Olchawa <pawel.olchawa@oracle.com> Reviewed-by:
Marcin Babij <marcin.babij@oracle.com> Reviewed-by:
Tor Didriksen <tor.didriksen@oracle.com>
Loading