[SERVER-6252] Debug assertion in Windows debug build, bad code in any build, due to incorrect lock usage Created: 29/Jun/12 Updated: 11/Jul/16 Resolved: 27/Jul/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 2.0.7 |
| Fix Version/s: | 2.0.7 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tad Marshall | Assignee: | Tad Marshall |
| Resolution: | Done | Votes: | 0 |
| Labels: | Windows | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows with journaling enabled |
||
| Issue Links: |
|
||||
| Operating System: | Windows | ||||
| Participants: | |||||
| Description |
|
The MemoryMappedFile::remapPrivateView() routine in Windows is using "RWLockRecursive::Exclusive lockMongoFiles(mmmutex)" to try to prevent other threads from accessing a memory-mapped file (the private view) while it is temporarily unmapped, but this code is called from "mongo::dur::_REMAPPRIVATEVIEW()" which has already taken out a shared lock on mmmutex. The release build does not complain about this, but it is wrong: the shared lock has set the recursion count to 1 and the exclusive lock sets it back to 0. If another thread tried to take out either a shared or an exclusive lock on mmmutex while we are in this state, it would think that it was the first locker and it would leak the previously allocated rwlock. The debug build, on the other hand, has a dassert() that tests the recursion count and aborts mongod.exe. We should probably take out an exclusive lock in _REMAPPRIVATEVIEW and (maybe, subject to code inspection) take out the exclusive lock in remapPrivateView. One way or another, we need to fix this incorrect usage of RWLockRecursive.
|
| Comments |
| Comment by Asya Kamsky [ 20/Oct/14 ] |
|
Paul, I believe this may be happening due to use of Windows32. As noted on the MongoDB downloads page Asya |
| Comment by Tad Marshall [ 27/Jul/12 ] |
|
Fixed by Eric in commit c88805a6f6447458290719703887fb736692359e . |
| Comment by Tad Marshall [ 29/Jun/12 ] |
|
Passing to Andy to decide how best to fix this. |