[SERVER-18372] QuerySolution leak when exception is thrown during PlanStage building Created: 07/May/15  Updated: 05/Apr/17  Resolved: 04/Oct/16

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

Type: Bug Priority: Major - P3
Reporter: Kamran K. Assignee: Robert Guo (Inactive)
Resolution: Done Votes: 0
Labels: 32qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-19510 Text query parsing should be moved to... Closed
is related to SERVER-18266 Standardize token-length limits betwe... Closed
is related to SERVER-21165 Leak in QueryPlannerAccess::makeLeafNode Closed
is related to SERVER-21166 Leak in getExecutorDistinct Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

JS test to trigger the leak:

var coll = db.fts;
coll.drop();
 
coll.ensureIndex({a: 'text'});
coll.find({$text: {$search: new Array(1024 * 16 + 2).join('a'), $language: 'zht'}}).itcount();

Sprint: TIG E (01/08/16), TIG F (01/29/16), TIG 2016-10-10
Participants:

 Description   

Triggering the RLP-token-length-limit error from SERVER-18266 leads to a leak during query execution:

Server command:
valgrind --show-leak-kinds=definite --leak-check=full --suppressions=./etc/valgrind.suppressions ./mongod --basisTechRootDirectory=/opt/basis/

Leak report:

==19816== Thread 1:
==19816== 37,235 (40 direct, 37,195 indirect) bytes in 1 blocks are definitely lost in loss record 5,512 of 5,525
==19816==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19816==    by 0x173FD58: mongo::QueryPlannerAnalysis::analyzeDataAccess(mongo::CanonicalQuery const&, mongo::QueryPlannerParams const&, mongo::QuerySolutionNode*) (planner_analysis.cpp:531)
==19816==    by 0x174B468: mongo::QueryPlanner::plan(mongo::CanonicalQuery const&, mongo::QueryPlannerParams const&, std::vector<mongo::QuerySolution*, std::allocator<mongo::QuerySolution*> >*) (query_planner.cpp:772)
==19816==    by 0x16F1163: mongo::(anonymous namespace)::prepareExecution(mongo::OperationContext*, mongo::Collection*, mongo::WorkingSet*, mongo::CanonicalQuery*, unsigned long, mongo::PlanStage**, mongo::QuerySolution**) (get_executor.cpp:364)
==19816==    by 0x16F1F22: mongo::getExecutor(mongo::OperationContext*, mongo::Collection*, mongo::CanonicalQuery*, mongo::PlanExecutor::YieldPolicy, mongo::PlanExecutor**, unsigned long) (get_executor.cpp:453)
==19816==    by 0x16F31FD: mongo::getExecutorFind(mongo::OperationContext*, mongo::Collection*, mongo::NamespaceString const&, mongo::CanonicalQuery*, mongo::PlanExecutor::YieldPolicy, mongo::PlanExecutor**) (get_executor.cpp:641)
==19816==    by 0x16EDEEB: mongo::runQuery(mongo::OperationContext*, mongo::QueryMessage&, mongo::NamespaceString const&, mongo::CurOp&, mongo::Message&) (find.cpp:560)
==19816==    by 0x15B889C: mongo::receivedQuery(mongo::OperationContext*, mongo::NamespaceString const&, mongo::Client&, mongo::DbResponse&, mongo::Message&) (instance.cpp:368)
==19816==    by 0x15B9205: mongo::assembleResponse(mongo::OperationContext*, mongo::Message&, mongo::DbResponse&, mongo::HostAndPort const&) (instance.cpp:504)
==19816==    by 0x128B8A9: mongo::MyMessageHandler::process(mongo::Message&, mongo::AbstractMessagingPort*) (db.cpp:167)
==19816==    by 0x1B12528: mongo::PortMessageServer::handleIncomingMsg(void*) (message_server_port.cpp:227)
==19816==    by 0x640F181: start_thread (pthread_create.c:312)



 Comments   
Comment by Robert Guo (Inactive) [ 04/Oct/16 ]

Verified against 3.3.15 that the leak is gone.

Comment by J Rassi [ 18/Nov/15 ]

I believe that this is fixed by SERVER-19510.

Kamran, would you please verify that this you can no longer reproduce this issue as of current master?

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