[
https://issues.apache.org/jira/browse/TRAFODION-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041326#comment-16041326
]
ASF GitHub Bot commented on TRAFODION-2636:
-------------------------------------------
Github user selvaganesang commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1113#discussion_r120700381
--- Diff: core/sql/optimizer/ControlDB.cpp ---
@@ -108,7 +108,12 @@ ControlDB::~ControlDB()
void ControlDB::setRequiredShape(ControlQueryShape *shape)
{
- delete requiredShape_;
+ if (requiredShape_)
+ {
+ delete requiredShape_->getShape();
+ delete requiredShape_;
--- End diff --
If the NADELETE macro can't be used, then it is fine to stick with delete.
However, NABasicObject also has the default constructor and hence it is
possible to create objects without heap. I guess overloaded delete operator
would take care of this too.
I preferred NADELETE macro because it is easy to read that it is being
deleted from the heap.
> Modest memory leak in metadata context and with CQS
> ---------------------------------------------------
>
> Key: TRAFODION-2636
> URL: https://issues.apache.org/jira/browse/TRAFODION-2636
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Affects Versions: 1.3-incubating
> Reporter: Hans Zeller
> Assignee: Hans Zeller
> Fix For: 2.2-incubating
>
>
> Selva pointed me to this leak. He found that we leak GroupAttributes objects
> in the metadata context.
> It turns out that the ControlDB object makes copies of CQD and CQS RelExpr
> trees and stores them in the context heap. This is not a good idea, since
> RelExpr and the associate GroupAttributes classes are not designed for heaps
> other than the statement heap. GroupAttributes, for example, hard-codes the
> statement heap in its constructor calls to ValueIdSets. That probably isn't a
> visible problem in ControlDB, however.
> For CQDs, the allocations and deallocations seem to match. For CQS, we
> allocate ControlQueryShape objects and also the actual shapes. However, we
> deallocate only the ControlQueryShape objects, not the shapes themselves.
> A simple, conservative fix is therefore to deallocate the shapes as well. In
> the longer term, it would be good to avoid storing RelExprs in the context
> heap.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
