[
https://issues.apache.org/jira/browse/TRAFODION-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563501#comment-15563501
]
ASF GitHub Bot commented on TRAFODION-2266:
-------------------------------------------
Github user sureshsubbiah commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/748#discussion_r82682913
--- Diff: core/sql/export/ComDiags.cpp ---
@@ -1671,8 +1671,8 @@ ComDiagsArea::ComDiagsArea (CollHeap* ptr):
IpcMessageObj(IPC_SQL_DIAG_AREA,0),
ComDiagsArea::ComDiagsArea () :
IpcMessageObj(IPC_SQL_DIAG_AREA,0),
collHeapPtr_(NULL),
- errors_(),
- warnings_(),
+ errors_(NULL),
--- End diff --
Yes.
This is the ComDiagsArea constructor without a heap pointer. There is
another one with a heap pointer. I see two options to avoid this leak
a) try to get rid of this constructor OR
b) Make sure that these NACollection objections are cleared at the end of
their lifecycle.
Either of them would take some effort. I don't have a fix that can be
included now. I would claim that this code does no worse than before here,
while making marginal improvements in other places. It also ensures that no one
unintentionally creates objects on the system heap.
> 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)
