[jira] [Created] (TRAFODION-2276) Complete list of memory leaks in SQL component due to NACollection objects being allocated in system heap

["Suresh Subbiah (JIRA)" <ji...@apache.org>]

Suresh Subbiah created TRAFODION-2276:
-----------------------------------------

             Summary: Complete list of memory leaks in SQL component due to NACollection objects being allocated in system heap
                 Key: TRAFODION-2276
                 URL: https://issues.apache.org/jira/browse/TRAFODION-2276
             Project: Apache Trafodion
          Issue Type: Bug
          Components: sql-general
    Affects Versions: any
            Reporter: Suresh Subbiah
            Assignee: Suresh Subbiah


When NACollection or its derived classes are called with NULL for the heap* then memory is allocated from the system heap. There could be leaks in such cases since several parts of Trafodion code rely on an NAHeap that is cleaned up as whole. With PR 748 NACollection derived class constructors will now require a heap pointer to be passed in even if it is NULL. 

With this PR the following is a list of NACollection class variables that are currently using NULL as their heap* . Each one of them must be individually analyzed to ensure that there is no memory leak. This is a complete list.

CmpISPFuncs::procFuncsArray_ in arkcmp/CmpStoredProc.cpp
Cmdline_Args::settings_      in arkcmp/cmpargs.cpp
ColIndList::ColIndList, derived from NAList in common/ColIndList.h
ExeTraceInfo::exeTraces_ in common/ComExeTrace.cpp
IpcConnection::recvStreams_ in common/Ipc.h
NAHeap::la_ in common/NAMemory.cpp (debug code use to store stack address)
CNATestPointList::NAList in common/NATestPoint.cpp (testing code)
NATraceList::NAList in common/NATraceList.cpp (testing code)
ComDiagsArea::errors_/warnings_ in export/ComDiagsArea.cpp (default constructor only)
PrivMgrDesc::columnLevel_ in sqlcomp/PrivMgrDesc.h
static NAList<SqlstateInfo*> listOfSqlstates_ in sqlmsg/GetErrorMessage.cpp

There are a couple of additional places where NULL is used but then setHeap is used immediately afterward or clear is called on those variables appropriately. In those instances we feel confident that there is no leak, and hence they are not listed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)