[ 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 <selva.govindara...@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 <selva.govindara...@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)