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

IDL objects should hold owned BSONObjs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.4
    • Component/s: IDL
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Platforms 2018-09-24
    • Linked BF Score:
      0

      Description

      When parsing BSONType::Object elements, the automatically-generated parse method will store a view of BSON in the spec, rather than an owned copy. For example,

      document_source_out_gen.cpp

      121
              else if (fieldName == kUniqueKeyFieldName) {
      122
                  if (MONGO_unlikely(usedFields[kUniqueKeyBit])) {
      123
                      ctxt.throwDuplicateField(element);
      124
                  }
      125
       
      126
                  usedFields.set(kUniqueKeyBit);
      127
       
      128
                  if (MONGO_likely(ctxt.checkAndAssertType(element, Object))) {
      129
                      _uniqueKey = element.Obj();
      130
                  }
      131
              }
      

      The spec then contains garbage if the original object used for parsing goes out-of-scope. Since the IDL already holds other owned types (e.g. std::string), we should strive to keep an owned copy of BSON.

      I don't think this affects existing users of the IDL, as in most usages the original command object is kept around for the lifetime of the command's execution. However, we'd like to serialize $out with the IDL in SERVER-36187, but our reparse-reserialization tests hit a segmentation violation.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mark.benvenuto Mark Benvenuto
              Reporter:
              kyle.suarez Kyle Suarez
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: