[
https://issues.apache.org/jira/browse/TRAFODION-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322643#comment-16322643
]
ASF GitHub Bot commented on TRAFODION-2879:
-------------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/trafodion/pull/1384
> Core dump due to reference to deallocated memory for EstLogProp object
> ----------------------------------------------------------------------
>
> Key: TRAFODION-2879
> URL: https://issues.apache.org/jira/browse/TRAFODION-2879
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Affects Versions: 2.0-incubating
> Environment: Any
> Reporter: Hans Zeller
> Assignee: Hans Zeller
> Fix For: 2.3
>
>
> This looks like an old bug that was recently found by Eric Owhadi, with a
> stack trace that looks like this:
> {noformat}
> #5 0x00007f23af4264fa in NAHeap::deallocateHeapMemory (this=0x7f237ddd66c0,
> addr=0x7f236f70fba8) at ../common/NAMemory.cpp:3230
> #6 0x00007f23af42207b in NAMemory::deallocateMemory (this=0x7f237ddd66c0,
> addr=0x7f236f70fba8) at ../common/NAMemory.cpp:1265
> #7 0x00007f23ada97cdd in NABasicObject::operator delete (p=0x7f236f70fba8)
> at ../export/NABasicObject.cpp:139
> #8 0x00007f23ac37fa24 in EstLogProp::~EstLogProp (this=0x7f236f70fba8,
> __in_chrg=<value optimized out>) at ../optimizer/EstLogProp.cpp:130
> #9 0x00007f23ac38117e in IntrusiveSharedRefCount<EstLogProp>::destroyObjects
> (
> this=0x7f236f70fbb8) at ../common/SharedPtr.h:226
> #10 0x00007f23ac1ce7de in SharedRefCountBase<EstLogProp>::decrUseCount (
> this=0x7f236f70fbb8) at ../common/SharedPtr.h:136
> #11 0x00007f23ac1cb845 in SharedPtr<EstLogProp>::~SharedPtr (
> ---Type <return> to continue, or q <return> to quit---
> this=0x7f2382e8e2d0, __in_chrg=<value optimized out>)
> at ../common/SharedPtr.h:280
> #12 0x00007f23ac1c591e in IntrusiveSharedPtr<EstLogProp>::~IntrusiveSharedPtr
> (
> this=0x7f2382e8e2d0, __in_chrg=<value optimized out>)
> at ../common/SharedPtr.h:376
> #13 0x00007f23ab92d85a in CmpContext::~CmpContext (this=0x7f2382e8e090,
> __in_chrg=<value optimized out>) at ../arkcmp/CmpContext.cpp:382
> {noformat}
> I suspect that we are trying to delete the CmpContext::emptyInLogProp_ data
> member here.
>
> I think this data member is initialized incorrectly:
>
> - The CmpContext object lives longer than an individual statement
> - Initially, CmpContext::emptyInLogProp_ is a NULL pointer
> - For every statement (or at least for most statements), we set this data
> member to an object allocated from the statement heap, see
> CmpStatement::initQueryAnalysis() in file arkcmp/CmpStatement.cpp.
> - We don’t deallocate this data member explicitly, as far as I can see. It
> gets automatically deleted when we call the destructor or when we assign a
> different value to the IntrusiveSharedPtr.
>
> So, what happens is that when we destroy the statement and its heap, we leave
> a dangling reference to a deallocated object in the CmpContext. As we can see
> here, when we later destroy the context, we point to an object in deallocated
> memory.
> We need to do two things to fix this: First, with these shared pointers, we
> cannot allocate an object from the statement heap without calling the
> destructor for the object. Second, we cannot point from the CmpContext to an
> object that is allocated from the short-lived statement heap - at least not
> beyond the lifetime of the statement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
