[SERVER-17720] Coverity analysis defect 66961: Resource leak Created: 24/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: David Storch
Resolution: Done Votes: 0
Labels: coverity
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

A new defect has been detected and assigned to david.storch in Coverity Connect.
http://coverity.mongodb.com//sourcebrowser.htm?projectId=10001#mergedDefectId=66961
The defect was flagged by checker RESOURCE_LEAK in
file /src/mongo/db/commands/find_cmd.cpp
function mongo::FindCmd::run(mongo::OperationContext *, const std::basic_string<char, std::char_traits<char>, std::allocator<char>>&, mongo::BSONObj &, int, std::basic_string<char, std::char_traits<char>, std::allocator<char>>&, mongo::BSONObjBuilder &, bool)
and this ticket was created by asya



 Comments   
Comment by David Storch [ 24/Mar/15 ]

If LiteParsedQuery::make() returns a non-OK status, then the caller is not responsible for freeing 'rawLPQ'. Therefore, I think Coverity is mistaken, and there is no memory leak here. Note that LiteParsedQuery::make() keeps the new LPQ instance in a std::auto_ptr, only releasing it on success.

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