[
https://issues.apache.org/jira/browse/TRAFODION-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563152#comment-15563152
]
ASF GitHub Bot commented on TRAFODION-2266:
-------------------------------------------
Github user selvaganesang commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/748#discussion_r82504380
--- Diff: core/sql/arkcmp/CmpStoredProc.cpp ---
@@ -733,7 +733,7 @@ CmpStoredProc::ExecStatus
CmpStoredProc::close(CmpSPDataObject&)
// Methods of CmpISPFuncs
// -----------------------------------------------------------------------
-NAList<CmpISPFuncs::ProcFuncsStruct> CmpISPFuncs::procFuncsArray_(256);
+NAList<CmpISPFuncs::ProcFuncsStruct>
CmpISPFuncs::procFuncsArray_(NULL,256);
--- End diff --
Can we use GetCliGlobals(false)->exCollHeap() here instead
> Fix a few memory leaks
> -----------------------
>
> Key: TRAFODION-2266
> URL: https://issues.apache.org/jira/browse/TRAFODION-2266
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-general
> Affects Versions: any
> Reporter: Suresh Subbiah
> Assignee: Suresh Subbiah
> Fix For: 2.1-incubating
>
>
> In the sql component of Trafodion memory for most objects derive from
> NABasicObject. The new/delete operators they use are overloaded to use memory
> managed by the NAHeap objects. This allows for memory to managed according to
> the component that is using it. It also make it somewhat easier to identify
> the source of a leak as various NAHeaps are used by different parts of the
> code. Collection objects such as Set, List, Array are derived from
> NACollection template base class. An NACollection object can be allocated on
> an NAHeap, and the memory it uses to allocate its storage as new objects are
> inserted can come for an NAHeap that is passed in during construction.
> However if no heap is passed in objects will be created in the global/system
> heap. This can lead to a leak since many parts of the code rely on something
> like StatementHeap (an NAHeap) to be deallocated as a whole it is no longer
> needed.
> This change removes constructors for derived classes on NACollection, what
> have no NAHeap argument. In other words from now on whenever an NaCollection
> derived object is created, the developer must explicitly specify the heap. If
> it should be system heap (no NAHeap is available/suitable), then NULL can be
> passed in (once NABasicObject.h is included). This is based on suggestions by
> Selva and Hans. Removing these constructors caused code to not compile. All
> compile failures have been fixed by making all calls to these constructors
> specify an explicit heap. Use of NULL for this explicit heap has been
> minimized to a large extent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
