[
https://issues.apache.org/jira/browse/TRAFODION-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Subbiah closed TRAFODION-2276.
-------------------------------------
Resolution: Duplicate
Duplicate of 2275
> 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)
