Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Issue Status as of Jul 24, 2014 ISSUE SUMMARY A logical bug in the query execution code would under certain circumstances output internal representations instead of the actual result documents. USER IMPACT The scope is very narrow and can only occur on complex queries when an index intersection plan is chosen. If returned documents look like {"":1234} (or any other number) this is an indication that this bug may be triggered. WORKAROUNDS N/A AFFECTED VERSIONS All production release versions from 2.6.0 to 2.6.3 are affected by this issue. FIX VERSION The fix is included in the 2.6.4 production release. RESOLUTION DETAILS Correctly handle hash intersections with fetched and non-fetched data. Original description After making some queries, mongo gets to inconsistent state: for some specific query it gives the response such as {"":1234} which is not a proper document (for example _id is missing). The bug vanishes when restarting mongodb server.
xgen-internal-githook commented on Thu, 24 Jul 2014 15:08:16 +0000: Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'} Message: SERVER-14607 fix compile for index intersection dbtest Branch: v2.6 https://github.com/mongodb/mongo/commit/15bef02ea778836c06d15e485a6a85a92c88bb80 xgen-internal-githook commented on Thu, 24 Jul 2014 13:02:26 +0000: Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'} Message: SERVER-14607 do not discard data while merging working set members for index intersection (cherry picked from commit 7acc48b74c6c0755e63a0358521055aae9792cd4) Branch: v2.6 https://github.com/mongodb/mongo/commit/84597954fac5ef20ff6ea47f3f6375b21b656299 xgen-internal-githook commented on Thu, 24 Jul 2014 12:59:52 +0000: Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'} Message: SERVER-14607 do not discard data while merging working set members for index intersection Branch: master https://github.com/mongodb/mongo/commit/7acc48b74c6c0755e63a0358521055aae9792cd4 tomas.kulich@gmail.com commented on Sat, 19 Jul 2014 20:03:19 +0000: Oh, it's good that you can create/restore dump while preserving the invalid state. For me, the DB gets repaired once I dumped/restored it. This was the reason, why I reported the bug this way Anyways, great that you can reproduce it, I'm shutting down the AWS instance. rassi@10gen.com commented on Fri, 18 Jul 2014 15:55:29 +0000: Uploaded "dump.tgz", a dump of the collection created by the provided script. To reproduce, restore the dump into a 2.6.3 instance and run the following: db.adminCommand({setParameter:1, internalQueryForceIntersectionPlans:true}); var doc = db.getSiblingDB("mongoProviderTest").getCollection('__clean_random_history').find({$query: {$or: [{$and: [{version: {$gt: 1}}, {before: {$gt: {}}}, {"before.a": "hello"}]}, {$and: [{version: {$gt: 1}}, {after: {$gt: {}}}, {"after.a": "hello"}]}], version: {$gt: 1}}, $orderby: {version: 1}}).next(); printjson(doc); assert.neq(undefined, doc.version); tomas.kulich@gmail.com: thanks for setting up the live instance for us to examine. We're able to reproduce the issue ourselves, so feel free to take the instance down. tomas.kulich@gmail.com commented on Fri, 18 Jul 2014 15:44:41 +0000: That's great! Thank you! hari.khalsa@10gen.com commented on Fri, 18 Jul 2014 15:43:24 +0000: Thanks for reporting this, tomas.kulich@gmail.com. We've identified the underlying issue and will have a fix very shortly. It will be included in the next release of 2.6. thomasr commented on Fri, 18 Jul 2014 10:44:13 +0000: Hi Tomas, Thanks for reporting this, and for providing a demo instance to illustrate the behavior. We will look into it and get back to you when we know more. Regards, Thomas tomas.kulich@gmail.com commented on Fri, 18 Jul 2014 10:24:21 +0000: one more thing - I never get this bug on mongo v. 2.4
To examine: 1. ssh ubuntu@54.77.0.143 (pw: #######) (this is standard AWS EC2 instance with Ubuntu Server 14.04 LTS and mongo 2.6.3 installed from official repositories) 2. run ./restart.sh located in /home/ubuntu 3. after cca 1 minute, the script should end, you can ignore its output 4. run mongo shell 5. 'use mongoProviderTest' 6. run this query: db.getCollection('__clean_random_history').find({$query: {$or: [{$and: [{version: {$gt: 1}}, {before: {$gt: {}}}, {"before.a": "hello"}]}, {$and: [{version: {$gt: 1}}, {after: {$gt: {}}}, {"after.a": "hello"}]}], version: {$gt: 1}}, $orderby: {version: 1}}) Each document in the output should look like {"":1234} which is clearly wrong. Restart mongodb service to see the proper output. additional notes: it is probably not matter of this specific installation, it fails on several different machines running different flavors of linux this EC2 instance was created solely for demonstrating this bug, you are sudoer, feel free to play with it as you want the restart.sh script only runs more sophisticated code written in Dart language. You should probably be able to reproduce this bug also on other machines: copy the appropriate files, install Dart SDK and run it. Note that even though Dart and mongoDart (connector library) are involved, this bug clearly cannot be blamed on them; no client should have the possibility to get the DB to inconsistent state.