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

dbtemprelease's destructor can fail to restore state and assert on failure

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5.5
    • Component/s: Concurrency
    • Labels:
      None
    • Operating System:
      ALL
    • Linked BF Score:
      0

      Description

      Currently dbtemprelease's destructor attempts to acquire the same lock type as was yielded and restore the thread's client context to its pre yield state. If the lock is a read lock and the context's namespace belongs to a database that was closed during the yield, restoring the context will fail and dbtemprelease's destructor will assert.

      Asserting in dbtemprelease's destructor seems particularly unsafe because as a raii class its destructor is designed to be called when another exception is active.

      There seems to be a way to detect an active stack unwinding exception in a destructor, but it may be unreliable and there is no way to replace this exception with a higher priority exception about an inability to recover the thread's client context.

      Provisionally two options for dealing with this are:

      • Implement a dbtemprelease with a destructor that cannot fail to restore state.
      • If dbtemprelease can fail to restore state, it should not be implemented as an raii class but perhaps instead using exception forwarding, maybe something like:

        	try {
        		releaseState();
        		doSomething();
        		restoreState();
        	} catch ( ... ) {
        		restoreState(); // may throw
        		throw;
        	}

      See SERVER-5101 for an example of the dbtemprelease destructor assertion.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              schwerin Andy Schwerin
              Reporter:
              aaron Aaron Staple
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: