[ 
https://issues.apache.org/jira/browse/TRAFODION-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah resolved TRAFODION-2266.
---------------------------------------
    Resolution: Fixed

> 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)

Reply via email to