[
https://issues.apache.org/jira/browse/TRAFODION-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041268#comment-16041268
]
ASF GitHub Bot commented on TRAFODION-2636:
-------------------------------------------
Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1113#discussion_r120693437
--- 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 --
@selvaganesang can you explain this more? When I look at the definition of
NADELETE, it explicitly says that NADELETE is **not** meant for NABasicObjects,
and we are dealing with NABasicObjects here. Is it that you don't trust the
method in which we put the heap pointer into NABasicObjects?
> 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)
