[SERVER-13789] Some nested queries trigger an assertion error Created: 30/Apr/14  Updated: 16/Nov/21  Resolved: 06/May/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.0, 2.6.1
Fix Version/s: 2.6.2, 2.7.1

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

Issue Links:
Depends
Duplicate
is duplicated by SERVER-13897 Assertion error when using $elemMatch... Closed
Operating System: ALL
Backport Completed:
Steps To Reproduce:

in mongo shell:

> use test
> db.test.ensureIndex({'bar.baz': 1})
> db.test.find({'foo': 'bar', '$and': [{'bar': {'$elemMatch': {'$or': [{'baz': 'foo'}]}}}]})
error: { "$err" : "assertion src/mongo/db/query/planner_access.cpp:851" }
 
> db.serverBuildInfo()
{
	"version" : "2.6.1-rc1-pre-",
	"gitVersion" : "116d7d799a6edea172e612767d0605a913f7a9f5",
	"OpenSSLVersion" : "",
	"sysInfo" : "Darwin mci-osx108-5.build.10gen.cc 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49",
	"loaderFlags" : "-fPIC -pthread -Wl,-bind_at_load -mmacosx-version-min=10.6",
	"compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -pipe -O3 -Wno-unused-function -Wno-deprecated-declarations -mmacosx-version-min=10.6",
	"allocator" : "system",
	"versionArray" : [
		2,
		6,
		1,
		-9
	],
	"javascriptEngine" : "V8",
	"bits" : 64,
	"debug" : false,
	"maxBsonObjectSize" : 16777216,
	"ok" : 1
}

Participants:

 Description   
Issue Status as of May 16, 2014

ISSUE SUMMARY
Queries which have the format below fail when there's an index reaching into the deepest subfield (y.z). The format is triggered by an $and operator that contains an $elemMatch with any indexed logical operator below it. This includes indexed $or, $not, and $ne below $elemMatch. For example:

db.test.find({x: 1, $and: [{y: {'$elemMatch': {'$or': [{z: 3}]}}}]})

USER IMPACT
Queries of this type will fail with an assertion error.

WORKAROUNDS
Rewrite the query if possible to avoid $elemMatch over the logical operator (e.g.: $or):

db.test.find({x: 1, $and: [{y: {'$elemMatch': {'$or': [{z: 3}, {z:4}]}}}]})

can be rewritten as:

db.test.find({x: 1, $and: [{$or: [{"y.z": 3}, {"y.z":4}]}]})

AFFECTED VERSIONS
MongoDB production releases 2.6.0 and 2.6.1 are affected.

FIX VERSION
The fix is included in the 2.6.2 production release.

RESOLUTION DETAILS
The special $elemMatch object handling now accounts for predicates tagged by the enumerator that are below non-bounds generating MatchExpression nodes. Previously, this code skipped these tagged predicates, producing zero index scan leafs as a result (causing us to hit the assertion which makes sure there is at least one index scan).

Original description.

We tried to upgrade to MongoDB 2.6 but encountered some queries that would not function anymore.

I isolated a minimal test case that triggers an assertion error in the query planner. The error occurs on 2.6.0 (tested on OSX and Linux 64bit) and latest nightly build (mongodb-osx-x86_64-116d7d799a6edea172e612767d0605a913f7a9f5-2014-04-22).



 Comments   
Comment by Githook User [ 15/May/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13789 recursively build data access for subnodes beneath elemMatch
(cherry picked from commit eb97470c0507020e3c0f1cc47751feaa777b5d2e)
Branch: v2.6
https://github.com/mongodb/mongo/commit/de14e3eed4040db2f105dada80100b9417c37045

Comment by Githook User [ 06/May/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13789 recursively build data access for subnodes beneath elemMatch
Branch: master
https://github.com/mongodb/mongo/commit/eb97470c0507020e3c0f1cc47751feaa777b5d2e

Comment by hari.khalsa@10gen.com [ 30/Apr/14 ]

Thank you for reporting! We will fix this shortly.

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