[SERVER-15501] Acquiring lock in any mode on the Locker without first acquiring the global lock in IX mode fails an invariant Created: 02/Oct/14 Updated: 10/Dec/14 Resolved: 02/Oct/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | 2.7.7 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Daly | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 0 |
| Labels: | 28qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Steps To Reproduce: | This code was taken from a threaded test. I don't think it needs to be threaded to hit the issue. Initialization code: And then this code in a loop Or pull from here: https://github.com/dalyd/mongo/commit/2d62983ae826a7674ac45b83d0986cb84f90befb |
| Participants: |
| Description |
|
Locking a resource MODE_X without first getting a global MODE_IX lock causes an invariant failure and crashes. 2014-10-02T09:45:58.583-0400 I - [perftestthr] Invariant failure request src/mongo/db/concurrency/lock_state.cpp 519 |
| Comments |
| Comment by Kaloian Manassiev [ 02/Oct/14 ] |
|
This is actually an expected behaviour and is documented in the locker API: https://github.com/mongodb/mongo/blob/master/src/mongo/db/concurrency/locker.h#L56. Perhaps it should be made more obvious, but this is the only hierarchical check that we do currently. |
| Comment by David Daly [ 02/Oct/14 ] |
|
From discussion with kaloian.manassiev, I thought that the lock should still operate without getting the intent lock first, although in actual operation you would get the intent lock first. |
| Comment by Eric Milkie [ 02/Oct/14 ] |
|
Isn't that correct behavior? I thought it was a logic error to lock a resource in mode X without gaining an intent lock on the parent resource first. |