...
BugZero found this defect 2715 days ago.
Not every collection has a UUID even when the server is in featureCompatibilityVersion=3.6. For example, as part of SERVER-30500, the "system.indexes" collection on a database won't have a UUID. This means that calls to Collection::uuid() in DbCheckJob::_getCollectionMetadata() may attempt to get the value from an uninitialized boost::optional, leading to a segmentation fault. auto collection = agd.getDb()->getCollection(opCtx, info.nss); if (!collection) { return false; } auto prev = UUIDCatalog::get(opCtx).prev(_dbName, *collection->uuid()); auto next = UUIDCatalog::get(opCtx).next(_dbName, *collection->uuid()); Note: Due to how updateUUIDSchemaVersion() is only called with upgrade=true when the "setFeatureCompatibilityVersion" version command is run, if we manually modify the featureCompatibilityVersion document, then we can make a scenario where the server wouldn't have UUIDs for its collections while still being in featureCompatibilityVersion=3.6 even when running with the WiredTiger storage engine.
xgen-internal-githook commented on Fri, 15 Sep 2017 22:47:05 +0000: Author: {'username': 'GeertBosch', 'name': 'Geert Bosch', 'email': 'geert@mongodb.com'} Message: SERVER-30935 Fix UUID catalog prev/next with non-existent UUIDs Branch: master https://github.com/mongodb/mongo/commit/340b87ead6e5b0b6f0a369e89105c32852a64c18 louis.williams commented on Fri, 8 Sep 2017 17:58:49 +0000: Because I forgot to include the SERVER ticket in the commit... https://github.com/mongodb/mongo/commit/955dfb45f2f67d2f4570912dbcddecbf3e7bb116
python buildscripts/resmoke.py repro_server30935.js --storageEngine mmapv1 repro_server30935.js (function() { "use strict"; assert.commandWorked(db.runCommand({create: "mycoll"})); assert.commandWorked(db.runCommand({drop: "mycoll"})); assert.commandWorked(db.runCommand({dbCheck: 1})); })();