[SERVER-19040] WhereMatchExpression::shallowClone can leak memory during interruption Created: 18/Jun/15  Updated: 25/Jan/17  Resolved: 19/Jun/15

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 3.1.4
Fix Version/s: 3.1.5

Type: Bug Priority: Major - P3
Reporter: Andy Schwerin Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: UT
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-16035 Leaks emanating from QueryPlannerAcce... Closed
Related
related to SERVER-16889 Query subsystem public API should use... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 5 06/26/16
Participants:
Linked BF Score: 0

 Description   

WhereMatchExpression::shallowClone allocates a new javascript scope object and re-parses the javascript from the original WhereMatchExpression. Because the parsing involves entering the javascript engine, it may throw an exception to indicate that the operation has been interrupted. When this happens, the new match expression is leaked.

It is not sufficient to delete the new expression and propagate the exception, because if the where expression object is a subexpression (say of an "or" expression), the bubbling exception will cause the parent to be leaked. That is to say, shallowClone on match expressions is not exception safe.



 Comments   
Comment by Githook User [ 19/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-19040 Fix uassert code
Branch: master
https://github.com/mongodb/mongo/commit/0825bb2c83936d76d927bef681805b6fc686105d

Comment by Githook User [ 19/Jun/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-19040 Do not let exceptions leak out of WhereMatchExpression::init.
Branch: master
https://github.com/mongodb/mongo/commit/f1f528db6bbf170bd915c421ec93a66716234587

Comment by Andy Schwerin [ 18/Jun/15 ]

This could hypothetically be a memory leak on the 3.0 branch, but it is likely to be rare and slow, given that it requires operations to be interrupted during the query parsing phase as opposed to the much longer query execution phase.

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