[ https://issues.apache.org/jira/browse/TRAFODION-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041398#comment-16041398 ]
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_r120712778 --- 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 -- Yes, one thing I don't like about NABasicObject is that the heap pointer is junk for NABasicObjects that are allocated on the stack. Fortunately that's not a problem here. The allocation/deallocation of objects is pretty clear in this file. Thanks again for finding this leak! > 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)