[SERVER-15485] CanonicalQuery::canonicalize can leak a LiteParsedQuery Created: 01/Oct/14  Updated: 11/Mar/15  Resolved: 07/Oct/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 2.6.6, 2.7.8

Type: Bug Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: J Rassi
Resolution: Done Votes: 0
Labels: 28qa, address-sanitizer, leak-sanitizer, memory-leak
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-16889 Query subsystem public API should use... Closed
Tested
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Steps To Reproduce:

Run mongod under a leak detector, and run jstests/core/geo_s2near.js. The last line of that test, which tests a fix for SERVER-13666, issues out-of-bounds legacy coordinates to a spherical near query. This causes uassert 17444 to trigger, raising an exception and leaking the LiteParsedQuery.

Participants:

 Description   

If MatchExpressionParser::parse in the 13 argument form of CanonicalQuery::canonicalize throws an exception (as can occur, for instance, at uassert 17444 in expression_geo.cpp,) then the LiteParsedQuery object returned from LiteParsedQuery::make will be leaked since it is not wrapped in an owning smart pointer.



 Comments   
Comment by Githook User [ 25/Nov/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-15485 CanonicalQuery::canonicalize() manage lpq with auto_ptr

(cherry picked from commit 80baa49b5dff32bc0eebdfb2ab07d057126dea8d)
Branch: v2.6
https://github.com/mongodb/mongo/commit/28afa1465ca07a6d6a34bf2c09affa120f64c835

Comment by Githook User [ 07/Oct/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-15485 CanonicalQuery::canonicalize() manage lpq with auto_ptr
Branch: master
https://github.com/mongodb/mongo/commit/80baa49b5dff32bc0eebdfb2ab07d057126dea8d

Generated at Thu Feb 08 03:38:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.