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 <[email protected]>
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 <[email protected]>
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.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
