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

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

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 2.5.5
    • Concurrency
    • None
    • ALL
    • 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

              schwerin@mongodb.com Andy Schwerin
              aaron Aaron Staple
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: