Server crashes from shell query?

32 views
Skip to first unread message

Therefore

unread,
Apr 26, 2013, 10:04:06 PM4/26/13
to mongo...@googlegroups.com
Windows 7 SP1
MSVS 2010
MongoDB 2.2.0

I get that this query may be stupid but why would it cause my server to crash? Shouldn't it be more tolerant of such stupidity? (There exists a compound index  {employeenum: 1, check: 1 })

> j = { query: { $or: [ { employeenum: { $lt: 1 } }, { check: { $lt: "B" } } ] }, $hint: { employeenum: 1, check: 1 }, orderby: { employeenum: -1, check: -1 }, $min: { eployeenum: 1, check: "B" } }

> db.employees.find(j)

At the server console:

Fri Apr 26 18:55:18 [conn13]  PAY.employees Assertion failure la <= 0xffffff c:\mongodb\src\mongo\db\btree.h 243
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\util\stacktrace.cpp(161)              mongo::printStackTrace+0x5b
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\util\log.cpp(435)                     mongo::logContext+0x72
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\util\assert_util.cpp(109)             mongo::verifyFailed+0x190
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btree.h(243)                       mongo::DiskLoc56Bit::operator=+0x7a
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btree.cpp(751)                     mongo::BtreeBucket<mongo::BtreeData_V1>::find+0x64
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btree.cpp(1512)                    mongo::BtreeBucket<mongo::BtreeData_V1>::locate+0x74
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btree.cpp(1506)                    mongo::BtreeBucket<mongo::BtreeData_V1>::locate+0xd2
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btreecursor.cpp(173)               mongo::BtreeCursorImpl<mongo::BtreeData_V1>::_locate+0xdd
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btreecursor.cpp(289)               mongo::BtreeCursor::initWithoutIndependentFieldRanges+0x1df
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\btreecursor.cpp(227)               mongo::BtreeCursor::make+0xba
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\queryoptimizer.cpp(296)            mongo::QueryPlan::newCursor+0x388
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\queryoptimizercursorimpl.cpp(821)  mongo::CursorGenerator::singlePlanCursor+0x189
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\queryoptimizercursorimpl.cpp(845)  mongo::CursorGenerator::generate+0xbf
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\queryoptimizercursorimpl.cpp(724)  mongo::NamespaceDetailsTransient::getCursor+0xbf
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\ops\query.cpp(662)                 mongo::queryWithQueryOptimizer+0x1a9
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\ops\query.cpp(1015)                mongo::runQuery+0x112f
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\instance.cpp(244)                  mongo::receivedQuery+0x155
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\instance.cpp(390)                  mongo::assembleResponse+0x37d
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\db\db.cpp(192)                        mongo::MyMessageHandler::process+0x133
Fri Apr 26 18:55:19 [conn13] mongod.exe  ...\src\mongo\util\net\message_server_port.cpp(86)  mongo::pms::threadRun+0x638
Fri Apr 26 18:55:19 [conn13] *** unhandled exception 0x80000003 at 0x000007FEFDF03172, terminating
Fri Apr 26 18:55:19 [conn13] *** stack trace for unhandled exception:
Fri Apr 26 18:55:19 [conn13] KERNELBASE.dll                                                      DebugBreak+0x2
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\util\debug_util.cpp(46)               mongo::mongo_breakpoint+0x22
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\util\debug_util.h(65)                 mongo::breakpoint+0x25
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\util\assert_util.cpp(116)             mongo::verifyFailed+0x2b0
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btree.h(243)                       mongo::DiskLoc56Bit::operator=+0x7a
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btree.cpp(751)                     mongo::BtreeBucket<mongo::BtreeData_V1>::find+0x64
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btree.cpp(1512)                    mongo::BtreeBucket<mongo::BtreeData_V1>::locate+0x74
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btree.cpp(1506)                    mongo::BtreeBucket<mongo::BtreeData_V1>::locate+0xd2
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btreecursor.cpp(173)               mongo::BtreeCursorImpl<mongo::BtreeData_V1>::_locate+0xdd
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btreecursor.cpp(289)               mongo::BtreeCursor::initWithoutIndependentFieldRanges+0x1df
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\btreecursor.cpp(227)               mongo::BtreeCursor::make+0xba
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\queryoptimizer.cpp(296)            mongo::QueryPlan::newCursor+0x388
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\queryoptimizercursorimpl.cpp(821)  mongo::CursorGenerator::singlePlanCursor+0x189
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\queryoptimizercursorimpl.cpp(845)  mongo::CursorGenerator::generate+0xbf
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\queryoptimizercursorimpl.cpp(724)  mongo::NamespaceDetailsTransient::getCursor+0xbf
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\ops\query.cpp(662)                 mongo::queryWithQueryOptimizer+0x1a9
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\ops\query.cpp(1015)                mongo::runQuery+0x112f
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\instance.cpp(244)                  mongo::receivedQuery+0x155
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\instance.cpp(390)                  mongo::assembleResponse+0x37d
Fri Apr 26 18:55:19 [conn13] mongod.exe      ...\src\mongo\db\db.cpp(192)                        mongo::MyMessageHandler::process+0x133
Fri Apr 26 18:55:19 [conn13] writing minidump diagnostic file mongo.dmp

Message has been deleted

William Zola

unread,
Apr 28, 2013, 1:38:43 AM4/28/13
to mongo...@googlegroups.com
Under normal circumstances, the server will not crash when it receives a malformed query. 

The stack trace you're getting is consistent with disk file corruption in your index.  To validate or disprove that theory, try dropping and rebuilding the index in question.

IMPORTANT NOTE: index build can be a long-running and blocking operation: don't run it on a production node when you need your application to be up.  If you have a replica set, you can run it on a secondary; restarting the secondary without --replSet and running on a different port is highly recommended for any maintenance operation of this sort.

 -William 

Therefore

unread,
Apr 28, 2013, 8:14:09 PM4/28/13
to mongo...@googlegroups.com
Hi William,

I had recreated the index several times. It doesn't appear to be the cause of the problem. I have no problem with:

db.employees.find({ query: { $or: [ { employeenum: { $gt: 5 } }, { check: { $gt: "E" } } ] }, $min: { employeenum: 5, check: "E" }, $maxScan: 2,  $explain: false })

Which fetches for the next document in the index after the document with keys 5 - "E". This works perfectly. I would have thought that the corollary to going backwards would be:

db.employees.find({ query: { $or: [ { employeenum: { $lt: 5 } }, { check: { $lt: "E" } } ] }, $max: { employeenum: 5, check: "E" }, orderby: { employeenum: -1, check: -1 }, $maxScan: 2,  $explain: false })

But that crashes the server. That is worrisome not just because it doesn't do what I want to do but that it crashes the server. Should I also infer that a corrupt index for one collection could cause the server to crash thereby killing all users?



Reply all
Reply to author
Forward
0 new messages