[
https://issues.apache.org/jira/browse/TRAFODION-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041264#comment-16041264
]
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_r120692519
--- 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 --
Yes, I added the following code to the GroupAttributes constructor to find
this leak, out of thousands of allocations it did:
> const char *loc;
>
> if ((long) this < 0x8000000)
> loc = "c++h";
> else if ((long) this > 0x7ff000000000)
> loc = "stck";
> else if (CmpCommon::statementHeap() == NULL)
> loc = "nost";
> else if (CmpCommon::statementHeap()->containsAddress(this))
> loc = "stmt";
> else if (CmpCommon::contextHeap()->containsAddress(this))
> loc = "ctxt";
> else
> loc = "unkn";
>
> printf("GroupAttributes1, %#018lx %s\n", (long) this, loc);
> 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)
