You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Hans Zeller (JIRA)" <ji...@apache.org> on 2017/06/07 19:51:18 UTC
[jira] [Resolved] (TRAFODION-2636) Modest memory leak in metadata
context and with CQS
[ https://issues.apache.org/jira/browse/TRAFODION-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hans Zeller resolved TRAFODION-2636.
------------------------------------
Resolution: Fixed
> 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)