Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-30935

dbCheck command assumes all collections have a UUID and causes the server to crash if they don't

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.5.13
    • Component/s: Storage
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      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}));
      })();
      

      Show
      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})); })();
    • Sprint:
      Storage 2017-09-11, Storage 2017-10-02
    • Linked BF Score:
      0

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            louis.williams Louis Williams
            Reporter:
            max.hirschhorn Max Hirschhorn
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: