[jira] [Commented] (TRAFODION-2727) Memory leak in the compiler part of the code in Trafodion

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TRAFODION-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146589#comment-16146589 ] 

ASF GitHub Bot commented on TRAFODION-2727:
-------------------------------------------

GitHub user selvaganesang opened a pull request:

    https://github.com/apache/incubator-trafodion/pull/1219

     [TRAFODION-2727] Memory leak in the compiler part of the code in Trafodion

     Compiler objects were refactored to use the heap infrastructure to ensure that it is accounted and allocated within the trafodion memory management.
        
    The commonly used NAType and derived classes are mostly created via heap, but the heap was not passed in the constructor. The embedded objects used the system heap though the container object is allocated in the compiler heap. This could result in memory leak when the container object isdestroyed.


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/selvaganesang/incubator-trafodion memory_leak

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-trafodion/pull/1219.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1219
    
----
commit f6f96a3474cda19902eb0d46e5a8c6a41e6314a5
Author: selvaganesang <se...@esgyn.com>
Date:   2017-06-16T22:26:20Z

    Fix for Memory leak in compiler
    
    Small category  (less than 24 characters) is accommodated as union of data members to store
    the metadata of large or medium category. Hence small category need not be deallocated.
    Medium category (strings between 24 and 254 characters) and Large category (above 254) are allocated
    from heap. In the original code, the medium category should have been deallocated as soon as NAString is
    deallocated.  But this code is not effective because medium category is commented out. The large category
    keeps track of reference count and it is deallocated when the reference count becomes zero.
    
    Without the change in FBString.h the medium category is considered as a small category. With my change,
    the medium category strings are now considered as large category and will undergo reference count concepts.
    Hence it will be deallocated assuming the reference counts work well.
    
    In addition, the most commonly used function CharType::generateTextThenSetDisplayDataType now
    uses heap passed to eliminate interspersing this allocation with allocation from system heap resulting
    in memory fragmentation.
    
    Added defensive code in ODBC layer which is being flagged as most memory allocator method by gprof.

commit 35a656be9c367beb2bc3f159be9364cfc3027c69
Author: selvaganesang <se...@esgyn.com>
Date:   2017-08-30T03:40:49Z

    [TRAFODION-2727] Memory leak in the compiler part of the code in Trafodion
    
    Compiler objects were refactored to use the heap infrastructure to ensure
    that it is accounted and allocated within the trafodion memory management.
    
    The commonly used NAType and derived classes are mostly created via heap,
    but the heap was not passed in the constructor. The embedded objects
    used the system heap though the container object is allocated in the compiler
    heap. This could result in memory leak when the container object is
    destroyed.

----


> Memory leak in the compiler part of the code in Trafodion
> ---------------------------------------------------------
>
>                 Key: TRAFODION-2727
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2727
>             Project: Apache Trafodion
>          Issue Type: Improvement
>          Components: sql-cmp
>    Affects Versions: any
>            Reporter: Selvaganesan Govindarajan
>            Assignee: Selvaganesan Govindarajan
>             Fix For: 2.3-incubating
>
>
> The master executor process like mxosrvr which has the compiler embedded within it, grows in virtual memory overtime.  Trafodion i uses its own memory management via  heap to manage its memory needs during execution.  The embedded compiler is also expected to use this infrastructure to manage its memory needs. However, while executor is being build using this infrastructure from ground up, it was an after thought in case of compiler. Some objects in trafodion mixup both its own heap and system heap while allocating leading to memory leak.    



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)