-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Concurrency
-
None
-
ALL
-
0
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.
- 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