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

Steps to Reproduce