[SERVER-15921] Segfault trying to take a resource locking in the kv catalog Created: 03/Nov/14  Updated: 19/Nov/14  Resolved: 04/Nov/14

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.7.8
Fix Version/s: 2.8.0-rc0

Type: Bug Priority: Minor - P4
Reporter: John Esmet Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Start up with a non mmapv1 storage engine with supportsDocLocking() == false.

Participants:

 Description   

In KVCatalog::_findEntry we have:

boost::scoped_ptr<Lock::ResourceLock> rLk;
if (!_isRsThreadSafe)
rLk.reset(new Lock::ResourceLock(opCtx->lockState(), catalogRID));

But during KVStorageEngine::finishInit(), opCtx->lockState() is null, so we crash.

I think the right thing to do is not take a lock at all in this case because if we don't have a lock state we're probably in startup (or other inherently single-threaded block)



 Comments   
Comment by Githook User [ 04/Nov/14 ]

Author:

{u'username': u'esmet', u'name': u'John Esmet', u'email': u'john.esmet@gmail.com'}

Message: SERVER-15921 Check for lock state in kv catalog

Check if we have a lock state before taking any locks in the kv catalog.
The assumption is that no lock state means we are in an inherently
single-threaded code block (like startup).

Signed-off-by: Matt Kangas <matt.kangas@mongodb.com>
Closes #855
Branch: master
https://github.com/mongodb/mongo/commit/8f1f165734da24f5b44ae468a59b0cb9746dfec7

Comment by John Esmet [ 03/Nov/14 ]

Here's the associated PR - https://github.com/mongodb/mongo/pull/855

I think it's possible this fix is short sighted (maybe the caller should just have a lock state instead of assuming that no lock state means no locks are necessary?)

I'll let you be the judge

Comment by Eliot Horowitz (Inactive) [ 03/Nov/14 ]

if you have a patch could help

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