[
https://issues.apache.org/jira/browse/TRAFODION-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563154#comment-15563154
]
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_r82661367
--- Diff: core/sql/common/Collections.h ---
@@ -2217,15 +2217,15 @@ template <class T> class NAArray : public
NACollection<T>
public :
// default constructor
- NAArray(CollIndex initialElements = 0) :
- NACollection<T>(initialElements) {}
+ //NAArray(CollIndex initialElements = 0) :
+ //NACollection<T>(initialElements) {}
--- End diff --
Can you please remove the commented out lines
> 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)
