[
https://issues.apache.org/jira/browse/TRAFODION-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041218#comment-16041218
]
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_r120685625
--- Diff: core/sql/common/NAMemory.h ---
@@ -468,6 +468,11 @@ NA_EIDPROC
NAMemoryType getType() { return type_; }
NA_EIDPROC
NABoolean getUsage(size_t* lastSegSize, size_t* freeSize, size_t*
totalSize);
+ // for debugging
+NA_EIDPROC
+ NABoolean containsAddress(void *addr)
+ { return NABlock::blockHolding(firstBlk_, addr) != NULL; }
+
--- End diff --
Please ignore this comment. I should have read the commit message
> 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)
