[SERVER-14607] Some index intersection plans return internal data instead of the correct result set. Created: 18/Jul/14  Updated: 11/Mar/15  Resolved: 24/Jul/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.3
Fix Version/s: 2.6.4, 2.7.4

Type: Bug Priority: Major - P3
Reporter: Tomas Kulich Assignee: David Storch
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File dump.tgz    
Issue Links:
Depends
Tested
Operating System: ALL
Backport Completed:
Steps To Reproduce:

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.
Participants:

 Description   
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.



 Comments   
Comment by Githook User [ 24/Jul/14 ]

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

Comment by Githook User [ 24/Jul/14 ]

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

Comment by Githook User [ 24/Jul/14 ]

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

Comment by Tomas Kulich [ 19/Jul/14 ]

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.

Comment by J Rassi [ 18/Jul/14 ]

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.

Comment by Tomas Kulich [ 18/Jul/14 ]

That's great! Thank you!

Comment by hari.khalsa@10gen.com [ 18/Jul/14 ]

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.

Comment by Thomas Rueckstiess [ 18/Jul/14 ]

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

Comment by Tomas Kulich [ 18/Jul/14 ]

one more thing - I never get this bug on mongo v. 2.4

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