[SERVER-29218] QuerySolutionNode not safely managed in all code paths Created: 15/May/17  Updated: 30/Oct/23  Resolved: 17/May/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 3.5.8

Type: Bug Priority: Major - P3
Reporter: Justin Seyster Assignee: Justin Seyster
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Query 2017-05-29
Participants:
Linked BF Score: 0

 Description   

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.



 Comments   
Comment by Githook User [ 17/May/17 ]

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

Generated at Thu Feb 08 04:20:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.