Skip to content
  • Jusufadis Bakamovic's avatar
    b8aef8ba
    Bug#29300927: MEMORY LEAK IN TEMPTABLE::HANDLER::CREATE* · b8aef8ba
    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: default avatarPawel Olchawa <pawel.olchawa@oracle.com>
    Reviewed-by: default avatarMarcin Babij <marcin.babij@oracle.com>
    Reviewed-by: default avatarTor Didriksen <tor.didriksen@oracle.com>
    b8aef8ba
    Bug#29300927: MEMORY LEAK IN TEMPTABLE::HANDLER::CREATE*
    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: default avatarPawel Olchawa <pawel.olchawa@oracle.com>
    Reviewed-by: default avatarMarcin Babij <marcin.babij@oracle.com>
    Reviewed-by: default avatarTor Didriksen <tor.didriksen@oracle.com>
Loading