[SERVER-6652] memory leak on Matcher validation failure after _where allocated Created: 31/Jul/12  Updated: 11/Jul/16  Resolved: 01/Nov/13

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

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Unassigned
Resolution: Done Votes: 0
Labels: query_triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

The Matcher manages memory for its _where object manually, with an explicit delete call in ~Matcher(). It is possible for a query validation error to trigger an exception in the Matcher() constructor after _where has been allocated. In this case, the _where object is never deallocated because the ~Matcher() destructor is never called.

The Where object will not yet have set up a javascript scope in this case (so no scope will be leaked). But the small Where object will be leaked, and if a user repeatedly sends bad queries these leaks will add up.

Test

t = db.t;
t.drop();
 
// Does not leak.
t.find( { $where:'true', a:{ $mod:[ 1 /* valid arg */, 0 ] } } ).itcount();
 
// Leaks, because $mod validation fails inside Matcher() constructor and _where is never deallocated.
t.find( { $where:'true', a:{ $mod:[ 0 /* invalid arg */, 0 ] } } ).itcount();



 Comments   
Comment by Benety Goh [ 01/Nov/13 ]

This defect is filed against the implementation of Matcher that used to live in src/mongo/db/matcher.h. That implementation was replaced in 2.5.0 (SERVER-6400)

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