[
https://issues.apache.org/jira/browse/TRAFODION-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563334#comment-15563334
]
ASF GitHub Bot commented on TRAFODION-2266:
-------------------------------------------
Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/748#discussion_r82665028
--- Diff: core/sql/arkcmp/CmpContext.cpp ---
@@ -139,7 +139,12 @@ CmpContext::CmpContext(UInt32 f, CollHeap * h)
optPCodeCache_(NULL), // just to be safe ...
CDBList_(NULL),
allControlCount_(0),
- optSimulator_(NULL)
+ optSimulator_(NULL),
+ hosts_(h),
+ invocationInfos_(h),
+ planInfos_(h),
--- End diff --
My bad, sorry for adding these leaks.
> 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)
