[SERVER-5724] dbtemprelease's destructor can fail to restore state and assert on failure Created: 30/Apr/12  Updated: 11/Jul/16  Resolved: 29/Oct/14

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: 2.5.5

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-5229 fix dbtemprelease Closed
Related
related to SERVER-8579 Consolidate Mongod Lock/Resource Sche... Closed
is related to SERVER-5101 Test failure in closeall.js Closed
Operating System: ALL
Participants:
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.



 Comments   
Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-5724 Mark dbtemprelase

{,cond,if}

destructors as throwing

This is a stop-gap solution to prevent c++11 builds from terminating when
relocking and reinitializing Client::Context fails. In c++11 destructors that
aren't explicitly marked as throwing are implicitly noexcept(true).

For similar reasons it is invalid to put dbtemprelease into a smart pointer
since the smart pointer's destructor isn't marked as throwing. The few places
that did that were also changed.

dbtemprelasewritelock is unused so it was removed rather than fixed.
Branch: master
https://github.com/mongodb/mongo/commit/e472493129c095170f1322a98af67bdf5208fe51

Comment by Andy Schwerin [ 22/May/12 ]

Further problem is appropriately invalidating parent contexts. Blech.

Generated at Thu Feb 08 03:09:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.