[SERVER-19712] Index spec with integer-overflowing sort value leads to 'invalid bounds' verify() failure Created: 02/Aug/15  Updated: 29/Oct/15  Resolved: 29/Oct/15

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

Type: Bug Priority: Major - P3
Reporter: Kamran K. Assignee: David Storch
Resolution: Duplicate Votes: 0
Labels: 32qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-21166 Leak in getExecutorDistinct Closed
Related
is related to SERVER-21165 Leak in QueryPlannerAccess::makeLeafNode Closed
Operating System: ALL
Participants:

 Description   

This bug has been present since at least 2.6.10. It's not reproducible with 2.4.12.

Repro script:

var t = db.foo;
t.drop();
 
// The query doesn't fail when using Math.pow(2, 32) - 1
// as an index spec value
t.ensureIndex({a: Math.pow(2, 32)});
t.find({a: {$gt: 0}}).itcount();


Server output:

INVALID BOUNDS: field #0['a']: [inf.0, 0.0)
kp = { a: 4294967296.0 }
scanDir = 1
Assertion failure 0 src/mongo/db/query/index_bounds_builder.cpp 881


Backtrace:

#0  0x00007ffff6fa020b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x000000000239a84e in mongo::breakpoint () at src/mongo/util/debugger.cpp:58
#2  0x000000000238aae5 in mongo::verifyFailed (expr=0x2e3fee4 "0", file=0x2e3ff58 "src/mongo/db/query/index_bounds_builder.cpp", line=881) at src/mongo/util/assert_util.cpp:140
#3  0x0000000001ece063 in mongo::IndexBoundsBuilder::alignBounds (bounds=0x7fffd4036870, kp=..., scanDir=1) at src/mongo/db/query/index_bounds_builder.cpp:881
#4  0x0000000001f0697f in mongo::QueryPlannerAccess::finishLeafNode (node=0x7fffd40367f0, index=...) at src/mongo/db/query/planner_access.cpp:566
#5  0x0000000001f08b3c in mongo::QueryPlannerAccess::buildIndexedDataAccess (query=..., root=0x7fffd405afc0, inArrayOperator=false, indices=..., params=...) at src/mongo/db/query/planner_access.cpp:1172
#6  0x0000000001f1bc63 in mongo::QueryPlanner::plan (query=..., params=..., out=0x7fffec6d64d0) at src/mongo/db/query/query_planner.cpp:747
#7  0x0000000001eb38a5 in mongo::(anonymous namespace)::prepareExecution (opCtx=0x7fffec6d7690, collection=0x7fffd4005090, ws=0x7fffd4036d10, canonicalQuery=0x7fffd4032240, plannerOptions=0, 
    rootOut=0x7fffec6d67a0, querySolutionOut=0x7fffec6d67a8) at src/mongo/db/query/get_executor.cpp:335
#8  0x0000000001eb4659 in mongo::getExecutor (txn=0x7fffec6d7690, collection=0x7fffd4005090, canonicalQuery=..., yieldPolicy=mongo::PlanExecutor::YIELD_AUTO, plannerOptions=0)
    at src/mongo/db/query/get_executor.cpp:422
#9  0x0000000001eb5f0e in mongo::getExecutorFind (txn=0x7fffec6d7690, collection=0x7fffd4005090, nss=..., canonicalQuery=..., yieldPolicy=mongo::PlanExecutor::YIELD_AUTO)
    at src/mongo/db/query/get_executor.cpp:612
#10 0x0000000001eae6e6 in mongo::runQuery (txn=0x7fffec6d7690, q=..., nss=..., result=...) at src/mongo/db/query/find.cpp:515
#11 0x0000000001d8b449 in mongo::receivedQuery (txn=0x7fffec6d7690, nss=..., c=..., dbResponse=..., m=...) at src/mongo/db/instance.cpp:377
#12 0x0000000001d8bd84 in mongo::assembleResponse (txn=0x7fffec6d7690, m=..., dbresponse=..., remote=...) at src/mongo/db/instance.cpp:505
#13 0x0000000001a2bc0d in mongo::MyMessageHandler::process (this=0x3a3ee20, m=..., port=0x39f4cb0) at src/mongo/db/db.cpp:165
#14 0x00000000023ad2e3 in mongo::PortMessageServer::handleIncomingMsg (arg=0x39f4cb0) at src/mongo/util/net/message_server_port.cpp:229
#15 0x00007ffff6f98182 in start_thread (arg=0x7fffec6d8700) at pthread_create.c:312
#16 0x00007ffff6cc547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Version: 928a5cf91c162ec0c56f32658454a7193de70509



 Comments   
Comment by David Storch [ 29/Oct/15 ]

This will be fixed under SERVER-21166. Resolving as a duplicate.

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