[SERVER-36531] Lock acquisition may throw despite presence of UninterruptibleLockGuard when WT tickets are exhausted Created: 08/Aug/18  Updated: 29/Oct/23  Resolved: 29/Aug/18

Status: Closed
Project: Core Server
Component/s: Concurrency, Storage
Affects Version/s: None
Fix Version/s: 4.0.3, 4.1.3

Type: Bug Priority: Major - P3
Reporter: Ian Boros Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Sprint: Storage NYC 2018-09-10
Participants:
Linked BF Score: 58

 Description   

When we create a DBLock, a global lock is created with "throw" interrupt behavior. The result is that we may propagate an exception from here when this call to checkForInterrupt throws.

Since there are some places where we acquire locks in dispose() methods (which we don't allow to throw), such as here, this is a problem.

Here's a full stack trace (I was able to produce this by creating a "NoInterruptsAllowedGuard", which disallows calls to checkForInterrupt() when active.

 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/operation_context.cpp:197:0: mongo::OperationContext::checkForInterruptNoAssert()
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/operation_context.cpp:169:0: mongo::OperationContext::checkForInterrupt()
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/util/concurrency/ticketholder.cpp:119:0: mongo::TicketHolder::waitForTicketUntil(mongo::OperationContext*, mongo::Date_t)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/util/concurrency/ticketholder.cpp:90:0: mongo::TicketHolder::waitForTicket(mongo::OperationContext*)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/concurrency/lock_state.cpp:307:0: mongo::LockerImpl::_acquireTicket(mongo::OperationContext*, mongo::LockMode, mongo::Date_t)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/concurrency/lock_state.cpp:320:0: mongo::LockerImpl::_lockGlobalBegin(mongo::OperationContext*, mongo::LockMode, mongo::Date_t)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/concurrency/d_concurrency.cpp:176:0: mongo::Lock::GlobalLock::_enqueue(mongo::LockMode, mongo::Date_t)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/concurrency/d_concurrency.cpp:157:0: mongo::Lock::GlobalLock::GlobalLock(mongo::OperationContext*, mongo::LockMode, mongo::Date_t, mongo::Lock::InterruptBehavior, mongo::Lock::GlobalLock::EnqueueOnly)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/concurrency/d_concurrency.cpp:143:0: mongo::Lock::GlobalLock::GlobalLock(mongo::OperationContext*, mongo::LockMode, mongo::Date_t, mongo::Lock::InterruptBehavior)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/concurrency/d_concurrency.cpp:216:0: mongo::Lock::DBLock::DBLock(mongo::OperationContext*, mongo::StringData, mongo::LockMode, mongo::Date_t)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/catalog_raii.cpp:63:0: mongo::AutoGetDb::AutoGetDb(mongo::OperationContext*, mongo::StringData, mongo::LockMode, mongo::Date_t)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/pipeline/document_source_cursor.cpp:268:0: mongo::DocumentSourceCursor::cleanupExecutor()
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/pipeline/document_source_cursor.cpp:254:0: mongo::DocumentSourceCursor::doDispose()
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/pipeline/document_source.h:458:0: mongo::DocumentSource::dispose()
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/pipeline/pipeline.cpp:328:0: mongo::Pipeline::dispose(mongo::OperationContext*)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/exec/plan_stage.h:279:0: mongo::PlanStage::dispose(mongo::OperationContext*)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/query/plan_executor.cpp:683:0: mongo::PlanExecutor::dispose(mongo::OperationContext*, mongo::CursorManager*)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/clientcursor.cpp:128:0: mongo::ClientCursor::dispose(mongo::OperationContext*)
 /data/mci/a31b453f7981568261a490b2163f8846/src/src/mongo/db/clientcursor.cpp:237:0: mongo::ClientCursorPin::deleteUnderlying()



 Comments   
Comment by Githook User [ 14/Sep/18 ]

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-36531 Lock acquisition may throw despite use of UninterruptibleLockGuard when WiredTiger tickets are exhausted

(cherry picked from commit 57b4b2216ffc7986440b87f9659e970e061b9f33)
Branch: v4.0
https://github.com/mongodb/mongo/commit/279a1f51b9a0ba2ccf988a75f99268221e13539d

Comment by Githook User [ 29/Aug/18 ]

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-36531 Lock acquisition may throw despite use of UninterruptibleLockGuard when WiredTiger tickets are exhausted
Branch: master
https://github.com/mongodb/mongo/commit/57b4b2216ffc7986440b87f9659e970e061b9f33

Generated at Thu Feb 08 04:43:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.