[SERVER-27246] Running applyOps with an op on a nonexistent database using mmapv1 will crash mongod Created: 01/Dec/16  Updated: 15/Apr/22  Resolved: 05/Dec/16

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 3.3.8
Fix Version/s: 3.4.1, 3.5.1

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-23326 applyOps should use a single WriteUni... Closed
related to SERVER-30830 applyOps should return NamespaceNotFo... Closed
related to SERVER-63907 Remove code or fix comment referring ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Steps To Reproduce:

Start mongod with mmapv1. Ensure p11 database does not exist.

db.runCommand({applyOps: [{op:"i", ns: "p11.dbref4", o:{_id:5, x:17}}]})

Sprint: Storage 2016-12-12
Participants:
Linked BF Score: 0

 Description   

See repro steps.

This crashes because we attempt to construct an OldClientContext while in an active WriteUnitOfWork.
OldClientContext will attempt to create a database if it doesn't exist.
Creating a database on mmapv1 will attempt to allocate a new ns file, and then try to flush the journal manually.
Flushing the journal requires the flush lock, which invariants that we are not in a WriteUnitOfWork.



 Comments   
Comment by Githook User [ 05/Dec/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-27246 fix atomic applyOps with nonexistent dbs

(cherry picked from commit 0b9be138fb58ea4ef2ca77ddebf53b6c76238a13)
Branch: v3.4
https://github.com/mongodb/mongo/commit/315f18af97c00abd9d84aa5d09ff18a8a33d57d6

Comment by Githook User [ 05/Dec/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-27246 fix atomic applyOps with nonexistent dbs
Branch: master
https://github.com/mongodb/mongo/commit/0b9be138fb58ea4ef2ca77ddebf53b6c76238a13

Comment by Eric Milkie [ 01/Dec/16 ]

This will only affect applyOps invocations that expect to create collections implicitly (via insert/updates to a non-existent collection). This bug doesn't affect users that are replaying oplog entries because replication always explictly creates collections.

One proposed solution to this is to detect when a database is missing, throw an exception, and then restart the applyOps command from scratch but in non-atomic mode. Non-atomic mode is already used for any applyOps arrays that contain 'c' ops.

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