[mlpack-svn] [MLPACK] #263: CoverTree and BinarySpaceTree Segmentation Fault during destruction

MLPACK Trac trac at coffeetalk-1.cc.gatech.edu
Fri Dec 21 13:44:33 EST 2012


#263: CoverTree and BinarySpaceTree Segmentation Fault during destruction
-------------------------------+--------------------------------------------
  Reporter:  trironk3          |        Owner:  rcurtin 
      Type:  defect            |       Status:  accepted
  Priority:  major             |    Milestone:          
 Component:  armadillo sparse  |   Resolution:          
  Keywords:                    |     Blocking:          
Blocked By:                    |  
-------------------------------+--------------------------------------------
Changes (by rcurtin):

  * status:  new => accepted


Comment:

 The issue was that PrefixedOutStream::operator<<(T) was generating copies.
 Those objects which were segfaulting are those which do not have proper
 copy constructors.

 The key change is this:

 {{{
 PrefixedOutStream::operator<<(T)
 }}}

 to this:

 {{{
 PrefixedOutStream::operator<<(const T&)
 }}}

 If we were to change it to simply 'T&' and not 'const T&', this would not
 work for temporaries (i.e. `Log::Warn << Range(5, 6);`) because
 temporaries are not functionally equivalent to references.  However,
 temporaries are functionally equivalent to const references, so changing
 the signature to 'const T&' avoids copies while at the same time not
 adversely impacting functionality.  This change is committed in r14043.

 However, the ticket's not quite done yet.  Those offending objects
 (MRKDStatistic, HRectBound, BinarySpaceTree, CoverTree, this and that)
 should at least have properly-written copy constructors.  Otherwise a user
 will accidentally copy them and then everything goes to hell at
 destruction time.

-- 
Ticket URL: <http://trac.research.cc.gatech.edu/fastlab/ticket/263#comment:1>
MLPACK <www.fast-lab.org>
MLPACK is an intuitive, fast, and scalable C++ machine learning library developed by the FASTLAB at Georgia Tech under Dr. Alex Gray.


More information about the mlpack-svn mailing list