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

Prevent SBE from using unowned values from storage after yield

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Query Execution 2021-04-05, Query Execution 2021-04-19, Query Execution 2021-05-03

      Currently, values read in SBE's scan stage are owned by storage engine. There could be a situation when the query reads the document from storage, and in the middle of processing the document, yield happens. Yield can lead to freeing up memory behind the document. If that happens, SBE will try to process invalid document.

      For example, consider the plan

      unwind arrayToIterate = arrayField
      project arrayField = getField(inputDocument, "a")
      scan readInto = inputDocument
      

      and input document

      {a: [1, 2, 3]}

      . Yield can happen after unwind returns ADVANCED, processing element 1, potentially freeing document stored in inputDocument slot and invalidating array in arrayField.

      Classic engine handles this case by making pessimistic copies.

      After talking with anton.korshunov, martin.neupauer and david.storch, we have come up with a different approach. ScanStage::save() should make a copy of a document read from storage. restore() method of all stages which use values from stages below should check if these values are still the same. For instance, UnwindStage::restore() should check if getViewOfValue() for the array is equal to the value it traverses. If not, stage should update its internal state to use new value. Project stage should always recompute all expressions, since they can use slot with changed values.

      We should make a quick WIP patch to test this approach. If we encounter any major problems, we can switch to making pessimistic copies for the time being.

            Assignee:
            martin.neupauer@mongodb.com Martin Neupauer
            Reporter:
            nikita.lapkov@mongodb.com Nikita Lapkov (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: