ISSUE SUMMARY
$where can cause a segfault when used in db.currentOp()
USER IMPACT
Mongod will crash with a stack trace showing an error in the mongo::Matcher::parseWhere method, similar to the following
Fri Nov 15 19:34:35.259 Backtrace: 0x10044c60b 0x100001121 0x1000013a2 0x7fff979285aa 0 0x10021a733 0x10021d43b 0x10021dcb9 0x10021e657 0x10021c14e 0x10021d619 0x10021dcb9 0x1002b472a 0x1002b2628 0x1002a7464 0x1002dbcf2 0x100240b14 0x1001ee10f 0x10000b682 0x100441fd9 0 mongod 0x000000010044c60b _ZN5mongo15printStackTraceERSo + 43 1 mongod 0x0000000100001121 _ZN5mongo10abruptQuitEi + 225 2 mongod 0x00000001000013a2 _ZN5mongo24abruptQuitWithAddrSignalEiP9__siginfoPv + 242 3 libsystem_platform.dylib 0x00007fff979285aa _sigtramp + 26 4 ??? 0x0000000000000000 0x0 + 0 5 mongod 0x000000010021a733 _ZN5mongo7Matcher10parseWhereERKNS_11BSONElementE + ...
SOLUTION
Mongod now returns the following error message when $where is used in db.currentOp():
no valid context found for $where
WORKAROUNDS
Users should avoid using $where in db.currentOp()
PATCHES
Production release v2.4.9 and v2.2.7 contain the fix for this issue, and production release v2.6.0 will have a brand new query engine, which does not contain this bug.
Using a $where predicate with db.currentOp() on mongod causes a null dereference. Matcher::parseWhere() accesses the current context to look up which namespace to pass to the Where constructor, but cc()->_context is null, since db.currentOp() never sets a context.
> db.currentOp({$where:function(){return true;}}) Fri Aug 16 04:45:35.459 trying reconnect to 127.0.0.1:27017
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeb733700 (LWP 5112)] mongo::Matcher::parseWhere (this=0x7ffff6b7a3c0, e=...) at src/mongo/db/matcher.cpp:432 warning: Source file is more recent than executable. 432 _where = new Where( cc().ns() ); (gdb) bt #0 mongo::Matcher::parseWhere (this=0x7ffff6b7a3c0, e=...) at src/mongo/db/matcher.cpp:432 #1 0x0000000000a47083 in mongo::Matcher::parseMatchExpressionElement (this=0x7ffff6b7a3c0, e=..., nested=false) at src/mongo/db/matcher.cpp:454 #2 0x0000000000a478c5 in mongo::Matcher::Matcher (this=0x7ffff6b7a3c0, jsobj=..., nested=false) at src/mongo/db/matcher.cpp:541 #3 0x00000000009f5aa8 in mongo::inProgCmd (m=..., dbresponse=...) at src/mongo/db/instance.cpp:170 #4 0x00000000009f82a1 in mongo::assembleResponse (m=..., dbresponse=..., remote=...) at src/mongo/db/instance.cpp:350 #5 0x00000000006e8b68 in mongo::MyMessageHandler::process (this=<optimized out>, m=..., port=0x7ffff6d00b80, le=0x7ffff6d01640) at src/mongo/db/db.cpp:194 #6 0x0000000000dc659e in mongo::PortMessageServer::handleIncomingMsg (arg=0x7ffff6a87ab0) at src/mongo/util/net/message_server_port.cpp:206 #7 0x00007ffff7bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007ffff6eda4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x0000000000000000 in ?? () (gdb)
Verified affects 2.2.5 and 2.4.5, and does not affect 2.0.9 and 2.5.1.
- is duplicated by
-
SERVER-12003 MongoDB server crushes when db.$cmd.sys.inprog is accessed from shell
- Closed
- is related to
-
SERVER-11731 $where inside of projection $elemMatch causes segmentation fault
- Closed