Info
ASAN is showing that the CollectionScanNode created by makeCollectionScan is getting leaked. There are a few paths that do not explicitly delete this object:
1) The MatchExpression shallowClone operation just after the CollectionScanNode creation can throw an exception.
2) At least one error path in QueryPlannerAnalysis::analyzeDataAccess() exits early without freeing the "solnRoot" QuerySolutionNode object.
Top User Comments
xgen-internal-githook commented on Wed, 17 May 2017 15:57:08 +0000:
Author:
{u'username': u'jseyster', u'name': u'Justin Seyster', u'email': u'justin.seyster@mongodb.com'}
Message: SERVER-29218 Use std:::unique_ptr to manage QuerySolutionNode objects
This started with a test failure caused by a QuerySolutionNode getting
leaked in QueryPlannerAccess::makeCollectionScan(). I converted the
leaky pointer to std::unique_ptr management and then I spread
std::unique_ptr to all the places that interact with
makeCollectionScan().
I may revisit this to use unique_ptrs for all QuerySolutionNode
references.
Branch: master
https://github.com/mongodb/mongo/commit/19cf9cd89bf4b9796fc8a9452c9fbe5bc4b6eb05
