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

SBE tracking of open stages is not exception safe

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Query Execution
    • ALL
    • QE 2021-12-27, QE 2022-01-10, QE 2022-02-07, QE 2022-01-24, QE 2023-02-20, QE 2023-03-06, QE 2023-03-20, QE 2023-04-03

      A number of stages track whether their child is open via a _childOpened boolean flag. This flag is usually set after calling open() on the child. For example:

       

          // From FilterStage.
          void open(bool reOpen) final {
              // <Other logic omitted>
              _children[0]->open(reOpen);// This might throw!
              _childOpened = true;
          } 

      Unfortunately, a call to open() may throw, in order to abort a trial period. If this happens, the stage's _childOpened flag is never set to true. This means that a call to close() on the parent stage will not result in the child stage being closed.

          // FilterStage.
          void close() final {
              // <Omitted>
              if (_childOpened) {
                  // This branch isn't taken if the exception is thrown on open().
                  _children[0]->close();
                  _childOpened = false;
              }
          } 

      In other words, after the exception is thrown, even closing() and opening() the plan leaves the tree in an invalid state. Attempting to use the plan may result in a server crash.

      We should do a full audit of all of the SBE stages and make sure this pattern is fixed in every case. Here are the two places I've encountered it:

      https://github.com/mongodb/mongo/blob/fbe42b59f77c645413ebb60f6d11df7acf9612ee/src/mongo/db/exec/sbe/stages/filter.h#L98-L99

      https://github.com/mongodb/mongo/blob/fbe42b59f77c645413ebb60f6d11df7acf9612ee/src/mongo/db/exec/sbe/stages/hash_agg.cpp#L167-L168

       

            Assignee:
            andrew.paroski@mongodb.com Drew Paroski
            Reporter:
            ian.boros@mongodb.com Ian Boros
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: