Details
-
Bug
-
Resolution: Done
-
Major - P3
-
None
-
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
- is duplicated by
-
SERVER-5229 fix dbtemprelease
-
- Closed
-
- is related to
-
SERVER-5101 Test failure in closeall.js
-
- Closed
-
- related to
-
SERVER-8579 Consolidate Mongod Lock/Resource Scheduling Logic
-
- Closed
-